Sind Nullen in einer relationalen Datenbank in Ordnung?

Question

Es gibt eine Denkschule, die besagt, dass Nullwerte in einer relationalen Datenbank nicht erlaubt sein sollten. Das heißt, das Attribut (die Spalte) einer Tabelle sollte keine Nullwerte zulassen. Da ich aus dem Bereich der Softwareentwicklung komme, verstehe ich das nicht. Es scheint so, als ob der Wert Null im Kontext des Attributs gültig ist und daher erlaubt sein sollte. Dies ist in Java sehr üblich, wo Objektreferenzen oft null sind. Da ich keine umfassende Erfahrung mit Datenbanken habe, frage ich mich, ob ich hier etwas übersehe.

Answer 1

Nullen sind aus der Perspektive der Datenbanknormalisierung negativ zu sehen. Der Gedanke ist, dass, wenn ein Wert nichts sein kann, man ihn in eine andere spärliche Tabelle aufteilen sollte, damit man keine Zeilen für Elemente benötigt, die keinen Wert haben.

Es ist ein Versuch, sicherzustellen, dass alle Daten gültig und wertvoll sind.

In manchen Fällen ist ein Null-Feld jedoch nützlich, vor allem, wenn Sie aus Leistungsgründen eine weitere Verknüpfung vermeiden wollen (obwohl dies kein Problem sein sollte, wenn die Datenbank-Engine richtig eingerichtet ist, außer in außergewöhnlichen Hochleistungsszenarien).

-Adam

Answer 2

Ein Argument gegen Nullen ist, dass sie keine klar definierte Interpretation haben. Wenn ein Feld null ist, kann das wie folgt interpretiert werden:

• Der Wert ist "Nothing" oder "Empty set".
• Es gibt keinen Wert, der für dieses Feld sinnvoll ist.
• Der Wert ist unbekannt.
• Der Wert ist noch nicht eingegeben worden.
• Der Wert ist ein leerer String (für Datenbanken, die nicht zwischen Nullen und leeren Strings unterscheiden).
• Eine anwendungsspezifische Bedeutung (z. B. "Wenn der Wert Null ist, dann verwende einen Standardwert").
• Es ist ein Fehler aufgetreten, der dazu geführt hat, dass das Feld einen Nullwert hat, obwohl es eigentlich keinen Wert haben sollte.

Einige Schemadesigner fordern, dass alle Werte und Datentypen wohldefinierte Interpretationen haben sollten, weshalb Nullen schlecht sind.

Answer 3

Das kommt darauf an.

Solange Sie verstehen, warum Sie die NULL s in der Datenbank ( die Auswahl muss für jede Spalte einzeln getroffen werden ) UND wie Sie sie interpretieren, ignorieren oder anderweitig mit ihnen umgehen wollen, sind sie in Ordnung.

Zum Beispiel kann eine Spalte wie NUM_CHILDREN - Was tun Sie, wenn Sie die Antwort nicht wissen - es sollte sein NULL . Meiner Meinung nach gibt es keine andere beste Option für die Gestaltung dieser Säule (selbst wenn Sie ein Kennzeichen haben, um festzustellen, ob die NUM_CHILDREN Spalte gültig ist, müssen Sie trotzdem einen Wert in dieser Spalte haben).

Andererseits, wenn Sie nicht zulassen, dass NULL s und spezielle reservierte Werte für bestimmte Fälle haben (anstelle von Flags), wie z.B. -1 für die Anzahl der Kinder, wenn diese wirklich unbekannt ist, müssen Sie diese in ähnlicher Weise behandeln, in Bezug auf Konventionen, Dokumentation usw.

Letztlich müssen die Probleme also durch Konventionen, Dokumentation und Konsistenz gelöst werden.

Die von Adam Davis in der obigen Antwort offenbar befürwortete Alternative der Normalisierung der Spalten auf sparse (oder nicht so sparse, im Fall der NUM_CHILDREN Beispiel oder jedes andere Beispiel, bei dem die meisten Daten bekannte Werte haben) Tabellen, die zwar in der Lage sind, alle NULLs zu eliminieren, sind in der allgemeinen Praxis nicht praktikabel.

In vielen Fällen, in denen ein Attribut nicht bekannt ist, macht es wenig Sinn, für jede einzelne Spalte eine Verbindung zu einer anderen Tabelle herzustellen, die es ermöglichen könnte NULL s in einem einfacheren Design. Der Overhead der Verknüpfungen und der Platzbedarf für die Primärschlüssel machen in der Realität wenig Sinn.

Dies erinnert an die Art und Weise, wie doppelte Zeilen durch Hinzufügen einer Kardinalitätsspalte eliminiert werden können. Theoretisch löst dies zwar das Problem, dass es keinen eindeutigen Schlüssel gibt, in der Praxis ist dies jedoch manchmal unmöglich - zum Beispiel bei großen Datenmengen. Die Puristen sind dann schnell dabei, stattdessen einen Ersatz-PK vorzuschlagen, doch die Vorstellung, dass ein bedeutungsloses Surrogat Teil eines Tupels (Zeile) in einer Relation (Tabelle) sein kann, ist aus Sicht der relationalen Theorie lächerlich.

Answer 4

Gegen die Verwendung von NULL gibt es verschiedene Einwände. Einige der Einwände beruhen auf der Datenbanktheorie. In der Theorie gibt es keinen Unterschied zwischen Theorie und Praxis. In der Praxis jedoch schon.

Es ist richtig, dass eine vollständig normalisierte Datenbank ganz ohne NULLS auskommen kann. Jede Stelle, an der ein Datenwert ausgelassen werden muss, ist eine Stelle, an der eine ganze Zeile ohne Informationsverlust ausgelassen werden kann.

In der Praxis ist die Zerlegung von Tabellen in diesem Ausmaß nicht sehr nützlich, und die Programmierung, die zur Durchführung einfacher CRUD-Operationen in der Datenbank erforderlich ist, wird eher mühsam und fehleranfällig als weniger.

Es gibt Stellen, an denen die Verwendung von NULLS zu Problemen führen kann: Diese drehen sich im Wesentlichen um die folgende Frage: Was bedeuten fehlende Daten wirklich? Ein NULL-Wert besagt eigentlich nur, dass in einem bestimmten Feld kein Wert gespeichert ist. Aber die Schlussfolgerungen, die Anwendungsprogrammierer aus fehlenden Daten ziehen, sind manchmal falsch, und das verursacht eine Menge Probleme.

Daten können aus einer Vielzahl von Gründen an einem Ort fehlen. Hier sind einige davon:

1. Die Daten sind in diesem Zusammenhang nicht anwendbar, z. B. der Vorname des Ehepartners bei einer alleinstehenden Person.

2. Der Benutzer eines Dateneingabeformulars hat ein Feld leer gelassen, und die Anwendung verlangt keine Eingabe in diesem Feld.

3. Die Daten wurden aus einer anderen Datenbank oder Datei in die Datenbank kopiert, und in der Quelle fehlten Daten.

4. Es gibt eine optionale Beziehung, die in einem Fremdschlüssel kodiert ist.

5. In einer Oracle-Datenbank wurde eine leere Zeichenfolge gespeichert.

Hier sind einige Richtlinien, wann NULLS vermieden werden sollten:

Wenn Abfrageautoren im Zuge der normalen erwarteten Programmierung eine Menge ISNULL-, NV-, COALESCE- oder ähnlichen Code schreiben müssen, um einen gültigen Wert für den NULL-Wert zu ersetzen. Manchmal ist es besser, die Ersetzung zum Zeitpunkt der Speicherung vorzunehmen, vorausgesetzt, das, was gespeichert wird, ist "Realität".

Wenn die Zählungen wahrscheinlich falsch sind, weil Zeilen mit NULL gezählt wurden. Oft kann dies vermieden werden, indem einfach count(MeinFeld) statt count(*) ausgewählt wird.

Hier gibt es eine Stelle, an der Sie sich unbedingt an NULLS gewöhnen und entsprechend programmieren sollten: immer dann, wenn Sie äußere Verknüpfungen wie LEFT JOIN und RIGHT JOIN verwenden. Der Sinn eines Outer-Joins im Gegensatz zu einem Inner-Join besteht darin, Zeilen zu erhalten, wenn einige passende Daten fehlen. Die fehlenden Daten werden als NULLS angegeben.

Mein Fazit: Man sollte die Theorie nicht verwerfen, ohne sie zu verstehen. Lernen Sie aber auch, wann Sie von der Theorie abweichen und wie Sie sie befolgen können.

Answer 5

Nullmarkierungen sind in Ordnung. Wirklich, das sind sie.