The Billion Dollar Mistake?

Gegendarstellung: NULL is NICHT der Fehler, der uns Milliarden kostet

Lukas Eder

(c) Shutterstock / Dooder

NULL ist zweifellos ein polarisierender Wert. Den zahlreichen Klagen, NULL sei aus Theorie-Sicht nicht vertretbar und in der Praxis für etliche Software-Abstürze verantwortlich, stellt Lukas Eder von jOOQ die Nützlichkeit von NULL entgegen.

Vor kurzem habe ich auf Quora diese Antwort gegeben. Die Frage war „Was ist die Bedeutung von NULL in SQL?“, und die meisten gegebenen Antworten liefen darauf hinaus, C.J. Date oder Tony Hoare zu zitieren und NULL unisono für „böse“ zu erklären. Also, jeder schimpft ständig auf NULL. Lasst mich dagegen anschimpfen.

Die Akademiker

Klar, Akademiker, die C.J. Date mögen, werden über NULL herziehen (man beachte Greg Kemnitz’s interessante Antwort auf Quora). Ich möchte daran erinnern, dass C.J. Date auch UNION ALL kritisiert hat, weil die rein relationale Theorie nur mit Mengen operiert und nicht mit Multimengen (engl. „bags“), wie SQL das tut. Während Mengen in der Theorie vermutlich wesentlich reiner sind als Multimengen, sind Multimengen in der Praxis einfach sehr nützlich.

Diese Leute jammern wahrscheinlich auch immer noch über die Tatsache, dass das durchaus nützliche SQL über das reine QUEL obsiegt hat, und ich mache ihnen keinen Vorwurf. Die Theorie ist immer schöner als die reale Welt, die den realen Anforderungen ausgesetzt ist.

Die Puristen

Es gibt auch andere Arten von Puristen, die loslaufen und jedem ihre Schwarz-Weiß-Ansichten beibringen wollen, welche für pragmatische Herangehensweisen im Sinne von „Das hängt davon ab…“ keinen Raum lassen. In solchen Situationen zeige ich immer gerne diesen witzigen Comic: New intern knows best: GOTO. Puristen mögen die extreme Abstraktion, wenn sie ihre Welt beschreiben, und solche Abstraktionen verlangen nach sehr einfachen Modellen, nicht nach Komplexität. NULL fügt dem SQL-„Modell“ enorme Komplexität hinzu und passt insofern nicht in ihre Sicht.

Fakt ist: Es kommt darauf an

Die einzige faktenbasierte Meinung ist immer diejenige, dass es keine klare Meinung gibt. NULL ist ein unglaublich nützlicher Wert, und in allen Sprachen / Modellen ist NULL in irgendeiner Form repräsentiert, die Kardinalitäten der folgenden Art modellieren wollen:

  • 0 or 1 (hier ist NULL nützlich)
  • exactly 1 (hier braucht man kein NULL)
  • 0 .. many (hier braucht man kein NULL)

Funktionale Programmiersprachen bedienen sich häufig der „Monade“ Optional (siehe Mario Fuscos hervorragende Erklärung, was eine Monade ist), um die 0-or-1-Kardinalität zu modellieren, aber das ist nur ein weiterer Weg zur Modellierung von NULL – den (möglicherweise) nicht vorhandenen Wert. Wenn Sie über Stil diskutieren möchten (in diesem Fall sollten Sie das lesen), spielt NULL vs. Optional vielleicht eine Rolle für Sie – aber im Grunde ist beides wirklich exakt das selbe. Wir tauschen hier einfach nur Leerstellen gegen geschweifte Klammern aus.

Der einzige Weg, wirklich ohne den abwesenden Wert auszukommen, wäre, die Optional Kardinalität nicht zu erlauben und stattdessen 0 … many zu nutzen, was weit weniger deskriptiv wäre.

Also, egal was Puristen oder Akademiker über eine perfekte Welt sagen, wir Entwickler brauchen mächtige Tools, die uns dabei helfen, unsere Arbeit zu erledigen – und NULL (oder „Optional“) ist eines dieser mächtigen Tools.

Einspruch: SQL NULL ist kein absenter Wert

Nun, der Vorbehalt gegen SQLs NULL lautet, dass es sich nicht wie ein absenter Wert verhält. Es ist der UNBEKANNTE Wert, wie andere auch schon erklärt haben. Dieser feine Unterschied hat großen Einfluss auf eine Vielzahl von Operationen und Prädikaten, die sich nicht sehr intuitiv verhalten, wenn man sich dieses Unterschiedes nicht bewusst ist. Einige Beispiele dafür (und es gibt viele mehr):

Sogar mit der Spezifizierung, dass SQL NULL ein unbekannter Wert ist, missbrauchen es viele Nutzer, um stattdessen den absenten Wert zu modellieren, was in den meisten Fällen auch gut funktioniert – bis man sich in einem Widerspruch verrennt. Es stellt sich heraus, dass der unbekannte Wert noch nützlicher als der absente Wert ist, weil er es erlaubt, die Dinge deskriptiver zu modellieren. Man mag glauben, dass die Verfügbarkeit zweier „spezieller“ Werte die Probleme lösen würde, wie etwa in JavaScript, das zwischen null (unbekannt) und undefined (absent) unterscheidet.

JavaScript selbst ist ein Sammelsurium an Nützlichkeiten, das sich umgekehrt proportional zu seiner Reinheit oder Schönheit verhält.

Also – langer Rede kurzer Sinn:

Sucht euch selbst euren Lieblingsplatz auf der Skala: Nützlich <-> Rein

Programmiersprachen und Datenmodelle sind immer ein Kompromiss zwischen Reinheit und Nützlichkeit. Sucht euch euren bevorzugten Platz auf der Skala, aber hört auf, darüber zu schimpfen, dass NULL böse sei. Oder wie Simon Peyton Jones sagte:

„Haskell is useless.“

.

Aufmacherbild: Finance risk concept von Shutterstock / Urheberrecht: Dooder

Geschrieben von
Lukas Eder
Lukas Eder
Lukas Eder ist leidenschaftlicher Java- und SQL-Entwickler. Er ist Gründer der Data Geekery GmbH, dem Unternehmen hinter jOOQ - die einfachste Art, um SQL in Java zu schreiben.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: