Sind Nullen in einer relationalen Datenbank in Ordnung? [geschlossen]

Es gibt eine Meinung, dass Nullwerte in einer relationalen Datenbank nicht zulässig sein sollten. Das heißt, das Attribut (Spalte) einer Tabelle sollte keine Nullwerte zulassen. Ich komme aus der Softwareentwicklung und verstehe das wirklich nicht. Es scheint, dass wenn null im Kontext des Attributs gültig ist, es erlaubt sein sollte. Dies ist in Java sehr häufig, wo Objektreferenzen häufig null sind. Ich habe keine umfangreiche Datenbankerfahrung und frage mich, ob mir hier etwas fehlt.

Nullen werden aus Sicht der Datenbanknormalisierung negativ betrachtet. Die Idee ist, dass wenn ein Wert nichts sein kann, Sie ihn wirklich in eine andere Tabelle mit geringer Dichte aufteilen sollten, sodass Sie keine Zeilen für Elemente benötigen, die keinen Wert haben.

Es wird versucht sicherzustellen, dass alle Daten gültig und bewertet sind.

In einigen Fällen ist es jedoch hilfreich, ein Nullfeld zu haben, insbesondere wenn Sie aus Leistungsgründen einen weiteren Join vermeiden möchten (obwohl dies kein Problem sein sollte, wenn das Datenbankmodul ordnungsgemäß eingerichtet ist, außer in Szenarien mit außergewöhnlicher Leistung).

-Adam

Ein Argument gegen Nullen ist, dass sie keine genau definierte Interpretation haben. Wenn ein Feld null ist, kann dies 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 wurde noch nicht eingegeben.
• Der Wert ist eine leere Zeichenfolge (für Datenbanken, die nicht zwischen Nullen und leeren Zeichenfolgen unterscheiden).
• Einige anwendungsspezifische Bedeutungen (z. B. "Wenn der Wert null ist, verwenden Sie einen Standardwert.")
• Es ist ein Fehler aufgetreten, der dazu geführt hat, dass das Feld einen Nullwert hat, wenn dies eigentlich nicht der Fall sein sollte.

Einige Schemadesigner fordern, dass alle Werte und Datentypen genau definierte Interpretationen haben, daher sind Nullen schlecht.

Es hängt davon ab, ob.

Solange Sie verstehen, warum Sie NULLs in der Datenbank zulassen ( die Auswahl muss auf Spaltenbasis getroffen werden ) UND wie Sie sie interpretieren, ignorieren oder auf andere Weise damit umgehen, sind sie in Ordnung.

Zum Beispiel eine Spalte wie NUM_CHILDREN- was machst du, wenn du die Antwort nicht kennst - sollte es sein NULL. Meiner Meinung nach gibt es keine andere beste Option für das Design dieser Spalte (selbst wenn Sie ein Flag haben, um festzustellen, ob die NUM_CHILDRENSpalte gültig ist, müssen Sie immer noch einen Wert in dieser Spalte haben).

Wenn Sie andererseits NULLs nicht zulassen und für bestimmte Fälle spezielle reservierte Werte haben (anstelle von Flags), wie z. B. -1 für die Anzahl der Kinder, wenn dies wirklich unbekannt ist, müssen Sie diese auf ähnliche Weise ansprechen, z Bedingungen für Konventionen, Dokumentation usw.

Letztendlich müssen die Probleme also mit Konventionen, Dokumentation und Konsistenz angegangen werden.

Die Alternative, wie anscheinend von Adam Davis in der obigen Antwort vertreten, besteht darin, die Spalten auf spärliche (oder nicht so spärliche, im Fall des NUM_CHILDRENBeispiels oder eines Beispiels, in dem die meisten Daten bekannte Werte haben) Tabellen zu normalisieren , während dies möglich ist Alle NULL-Werte entfernen, ist in der allgemeinen Praxis nicht funktionsfähig.

In vielen Fällen, in denen ein Attribut unbekannt ist, ist es wenig sinnvoll, für jede einzelne Spalte eine andere Tabelle zu erstellen, was NULLein einfacheres Design ermöglichen könnte. Der Overhead von Joins und der Platzbedarf für die Primärschlüssel sind in der realen Welt wenig sinnvoll.

Dies erinnert daran, wie doppelte Zeilen durch Hinzufügen einer Kardinalitätsspalte beseitigt werden können, während theoretisch das Problem gelöst wird, keinen eindeutigen Schlüssel zu haben, was in der Praxis manchmal unmöglich ist - beispielsweise bei großen Datenmengen. Die Puristen schlagen dann schnell eine Ersatz-PK vor, doch die Idee, dass eine bedeutungslose Ersatz-PK Teil eines Tupels (einer Reihe) in einer Beziehung (Tabelle) sein kann, ist aus Sicht der relationalen Theorie lächerlich.

Nullmarker sind in Ordnung. Wirklich.

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

Es ist wahr, dass eine vollständig normalisierte Datenbank überhaupt ohne NULL auskommen kann. Jeder Ort, an dem ein Datenwert weggelassen werden muss, ist ein Ort, an dem eine ganze Zeile ohne Informationsverlust weggelassen werden kann.

In der Praxis dient das Zerlegen von Tabellen in diesem Ausmaß keinem großen nützlichen Zweck, und die zur Ausführung einfacher CRUD-Operationen an der Datenbank erforderliche Programmierung wird mühsamer und fehleranfälliger als weniger.

Es gibt Stellen, an denen die Verwendung von NULLS Probleme verursachen kann: Im Wesentlichen geht es um die folgende Frage: Was bedeuten fehlende Daten wirklich? Alles, was ein NULL wirklich vermittelt, ist, dass in einem bestimmten Feld kein Wert gespeichert ist. Aber die Schlussfolgerungen, die Anwendungsprogrammierer aus fehlenden Daten ziehen, sind manchmal falsch, und das verursacht viele Probleme.

Daten können aus verschiedenen Gründen an einem Ort fehlen. Hier sind ein paar:

1. Die Daten sind in diesem Zusammenhang nicht anwendbar. zB Vorname des Ehepartners für eine einzelne Person.

2. Der Benutzer eines Dateneingabeformulars hat ein Feld leer gelassen, und für die Anwendung ist keine Eingabe in das Feld erforderlich.

3. Die Daten werden 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 codiert ist.

5. Eine leere Zeichenfolge wurde in einer Oracle-Datenbank gespeichert.

Hier sind einige Richtlinien, wann Sie NULL-Werte vermeiden sollten:

Wenn im Verlauf der normalen erwarteten Programmierung Abfrageschreiber viel ISNULL-, NV-, COALESCE- oder ähnlichen Code schreiben müssen, um NULL durch einen gültigen Wert zu ersetzen. Manchmal ist es besser, die Ersetzung zur Ladenzeit vorzunehmen, vorausgesetzt, das, was gespeichert wird, ist "Realität".

Wenn die Anzahl wahrscheinlich nicht stimmt, weil Zeilen mit einem NULL-Wert gezählt wurden. Oft kann dies vermieden werden, indem nur count (MyField) anstelle von count (*) ausgewählt wird.

Hier ist ein Ort, an dem Sie sich besser an NULLS gewöhnen und entsprechend programmieren können: Wann immer Sie anfangen, äußere Verknüpfungen wie LEFT JOIN und RIGHT JOIN zu verwenden. Der springende Punkt hinter einem äußeren Join im Unterschied zu einem inneren Join ist das Abrufen von Zeilen, wenn einige übereinstimmende Daten fehlen. Die fehlenden Daten werden als NULL angegeben.

Mein Fazit: Entlassen Sie die Theorie nicht, ohne sie zu verstehen. Aber lernen Sie, wann Sie von der Theorie abweichen und wie Sie ihr folgen können.

Es ist nichts Falsches daran, NULL für Datenfelder zu verwenden. Sie müssen vorsichtig sein, wenn Sie Schlüssel auf Null setzen. Primärschlüssel sollten niemals NULL sein. Fremdschlüssel können null sein, aber Sie müssen darauf achten, keine verwaisten Datensätze zu erstellen.

Wenn etwas "nicht vorhanden" ist, sollten Sie NULL anstelle einer leeren Zeichenfolge oder einer anderen Art von Flag verwenden.

Anstatt alle Probleme von NULL und Tristate vs Boolean Logic usw. aufzuschreiben, werde ich diesen markigen Rat geben:

1. Lassen Sie NULL nicht in Ihren Spalten zu, bis Sie einen magischen Wert hinzufügen, der fehlende oder unvollständige Daten darstellt.

2. Da Sie diese Frage stellen, sollten Sie sehr vorsichtig sein, wie Sie sich NULL nähern. Es gibt viele nicht offensichtliche Fallstricke. Verwenden Sie im Zweifelsfall nicht NULL.

Es gibt eine andere Alternative zur Verwendung von "N / A" oder "N / K" oder der leeren Zeichenfolge - eine separate Tabelle.

ZB wenn wir die Telefonnummer eines Kunden kennen oder nicht:

CREATE TABLE Customer (ID int PRIMARY KEY, Name varchar(100) NOT NULL, Address varchar(200) NOT NULL);
CREATE TABLE CustomerPhone (ID int PRIMARY KEY, Phone varchar(20) NOT NULL, CONSTRAINT FK_CustomerPhone_Customer FOREIGN KEY (ID) REFERENCES Customer (ID));

Wenn wir die Telefonnummer nicht kennen, fügen wir der zweiten Tabelle keine Zeile hinzu.

Ich würde sagen, dass auf jeden Fall Nullen verwendet werden sollten. Es gibt keinen anderen richtigen Weg, um fehlende Daten darzustellen. Zum Beispiel wäre es falsch, eine leere Zeichenfolge zu verwenden, um eine fehlende Adresszeile darzustellen, oder es wäre falsch, 0 zu verwenden, um ein fehlendes Altersdatenelement darzustellen. Weil sowohl eine leere Zeichenfolge als auch 0 Daten sind. Null ist der beste Weg, um ein solches Szenario darzustellen.

Unterschätzen Sie nicht die Komplexität, die Sie erstellen, indem Sie ein Feld NULL-fähig machen. Zum Beispiel sieht die folgende where-Klausel so aus, als würde sie mit allen Zeilen übereinstimmen (Bits können nur 1 oder 0 sein, oder?)

where bitfield in (1,0)

Aber wenn das Bitfeld NULL-fähig ist, werden einige fehlen. Oder stellen Sie folgende Frage:

select * from mytable
where id not in (select id from excludetable)

Wenn die Ausschlusstabelle eine Null und eine 1 enthält, bedeutet dies:

select * from mytable
where id <> NULL and id <> 1

"Id <> NULL" ist jedoch für jeden Wert von id falsch, sodass niemals Zeilen zurückgegeben werden. Dies überrascht sogar erfahrene Datenbankentwickler.

Angesichts der Tatsache, dass die meisten Menschen von NULL überrascht werden können, versuche ich, dies zu vermeiden, wenn ich kann.

Dies ist eine riesige Dose Würmer, weil NULL so viele Dinge bedeuten kann:

• Kein Todesdatum, da die Person noch lebt.
• Keine Handynummer, weil wir nicht wissen, was es ist oder ob es existiert.
• Keine Sozialversicherungsnummer, da diese Person bekanntermaßen keine hat.

Einige davon können durch Normalisierung vermieden werden, einige können durch das Vorhandensein eines Wertes in dieser Spalte ("N / A") vermieden werden, einige können durch eine separate Spalte zur Erklärung des Vorhandenseins von NULL gemildert werden ("N / K", "N / A" usw.).

Es ist auch eine Dose Würmer, da sich die zum Auffinden erforderliche SQL-Syntax von der von Nicht-Null-Werten unterscheidet, es schwierig ist, sie zu verknüpfen, und sie im Allgemeinen nicht in Indexeinträgen enthalten sind.

Aus dem früheren Grund werden Sie Fälle finden, in denen eine Null unvermeidbar ist.

Aus dem letzteren Grund sollten Sie immer noch Ihr Bestes tun, um die Anzahl zu minimieren.

Verwenden Sie unabhängig davon immer NOT NULL-Einschränkungen, um sich vor Nullen zu schützen, wenn ein Wert erforderlich ist.

Das Hauptproblem bei Nullen besteht darin, dass sie über eine spezielle Semantik verfügen, die mit Vergleichen, Aggregaten und Verknüpfungen zu unerwarteten Ergebnissen führen kann.

• Nichts ist jemals gleich null und nichts ist jemals ungleich größer oder kleiner als null. Sie müssen also Nullen auf einen Platzhalterwert setzen, wenn Sie einen Massenvergleich durchführen möchten.

• Dies ist auch ein Problem bei zusammengesetzten Schlüsseln, die in einem Join verwendet werden können. Wenn der natürliche Schlüssel eine nullfähige Spalte enthält, sollten Sie einen synthetischen Schlüssel verwenden.

• Nullen können aus der Anzahl herausfallen, was möglicherweise nicht die gewünschte Semantik ist.

• Nullen in einer Spalte, gegen die Sie eine Verknüpfung herstellen können, entfernen Zeilen aus einer inneren Verknüpfung. Im Allgemeinen ist dies wahrscheinlich erwünschtes Verhalten, aber es kann Elefantenfallen für Personen legen, die Bericht erstatten.

Es gibt noch einige andere Feinheiten bei Nullen. Joe Celkos SQL for Smarties enthält ein ganzes Kapitel zu diesem Thema und ist ein gutes Buch, das es trotzdem wert ist, gelesen zu werden. Einige Beispiele für Orte, an denen Nullen eine gute Lösung sind, sind:

• Optionale Beziehungen, in denen eine verbundene Entität vorhanden sein kann oder nicht. Null ist die einzige Möglichkeit, eine optionale Beziehung in einer Fremdschlüsselspalte darzustellen.

• Spalten, die Sie möglicherweise für null verwenden möchten, um die Anzahl zu verringern.

• Optionale numerische Werte (z. B. Währung), die vorhanden sein können oder nicht. In Zahlensystemen gibt es keinen effektiven Platzhalterwert für "nicht erfasst" (insbesondere wenn Null ein zulässiger Wert ist), daher ist Null wirklich der einzig gute Weg, dies zu tun.

Einige Beispiele für Stellen, an denen Sie die Verwendung von Nullen vermeiden möchten, da diese wahrscheinlich subtile Fehler verursachen.

• 'Nicht aufgezeichnet' Werte in Codefeldern mit einem FK gegen eine Referenztabelle. Verwenden Sie einen Platzhalterwert, damit Sie (oder ein zufälliger Geschäftsanalyst) bei einer Abfrage für die Datenbank nicht versehentlich Zeilen aus den Ergebnismengen löschen.

• Beschreibungsfelder, in denen nichts eingegeben wurde - null string ( '') funktioniert hierfür einwandfrei. Dies erspart es, die Nullen als Sonderfall zu behandeln.

• Optionale Spalten in einem Berichts- oder Data Warehouse-System. Erstellen Sie in diesem Fall eine Platzhalterzeile für "Nicht aufgezeichnet" in der Dimension und verbinden Sie sich dagegen. Dies vereinfacht das Abfragen und funktioniert gut mit Ad-hoc-Berichterstellungstools.

Auch hier ist Celkos Buch eine gute Behandlung des Themas.

Das Beste, was Sie über Normalformen wissen sollten, ist, dass es sich um Führer handelt und dass Führer nicht hartnäckig befolgt werden sollten. Wenn die Welt der Wissenschaft mit der tatsächlichen Welt zusammenstößt, findet man selten viele überlebende Krieger der Acedämie.

Die Antwort auf diese Frage ist, dass es in Ordnung ist, Nullen zu verwenden. Bewerten Sie einfach Ihre Situation und entscheiden Sie, ob sie in der Tabelle angezeigt werden sollen, oder reduzieren Sie die Daten in eine andere verwandte Tabelle, wenn Sie der Meinung sind, dass das Verhältnis von Nullwerten zu tatsächlichen Werten zu hoch ist.

Wie ein Freund gern sagt: "Lass das Vollkommene nicht der Feind des Guten sein". Denken Sie, Voltaire hat das auch gesagt. 8)

Gemäß der strengen relationalen Algebra werden Nullen nicht benötigt. Für jedes praktische Projekt werden sie jedoch benötigt.

Erstens sind viele reale Daten unbekannt oder nicht anwendbar, und Nullen implementieren dieses Verhalten gut. Zweitens machen sie Ansichten und äußere Verbindungen viel praktischer.

Bei schrittweisen Datenerfassungssystemen werden Sie feststellen, dass Sie Nullen in einer Datenbank nicht vermeiden können, da die Reihenfolge der Fragen / Datenerfassung sehr selten mit dem logischen Datenmodell übereinstimmt.

Oder Sie können die Werte als Standard festlegen (Code ist erforderlich, um diese Standardwerte zu verarbeiten). Sie können beispielsweise in Ihrem Modell davon ausgehen, dass alle Zeichenfolgen leer statt null sind.

Sie können auch Staging-Datenbanktabellen für die Datenerfassung verwenden, die fortgesetzt werden, bis alle Daten abgerufen wurden, bevor Sie die tatsächlichen Datenbanktabellen füllen. Das ist viel zusätzliche Arbeit.

In einer Datenbank bedeutet null "Ich habe keinen Wert dafür". Dies bedeutet, dass (interessanterweise) eine boolesche Spalte, die Nullen zulässt, durchaus akzeptabel ist und in vielen Datenbankschemata vorkommt. Wenn Sie dagegen einen Booleschen Wert in Ihrem Code haben, der den Wert 'true', 'false' oder 'undefined' haben kann, wird Ihr Code wahrscheinlich früher oder später auf dem täglichen wwf angezeigt :)

Ja, wenn Sie die Möglichkeit berücksichtigen müssen, dass ein Feld überhaupt keinen Wert hat, ist das Zulassen von Nullen in der Spalte durchaus akzeptabel. Es ist deutlich besser als die möglichen Alternativen (leere Zeichenfolgen, Null usw.)

Es kann schwierig sein, mit Nullen zu arbeiten, aber in einigen Fällen sind sie sinnvoll.

Angenommen, Sie haben eine Rechnungstabelle mit einer Spalte "PaidDate", die einen Datumswert hat. Was geben Sie in diese Spalte ein, bevor die Rechnung bezahlt wurde (vorausgesetzt, Sie wissen vorher nicht, wann sie bezahlt wird)? Es kann keine leere Zeichenfolge sein, da dies kein gültiges Datum ist. Es ist nicht sinnvoll, ein beliebiges Datum anzugeben (z. B. 1.1.1900), da dieses Datum einfach nicht korrekt ist. Es scheint, dass der einzig vernünftige Wert NULL ist, da er keinen Wert hat.

Das Arbeiten mit Nullen in einer Datenbank ist mit einigen Herausforderungen verbunden, die von Datenbanken jedoch gut gehandhabt werden. Die wirklichen Probleme sind, wenn Sie Nullen aus Ihrer Datenbank in Ihren Anwendungscode laden. Dort habe ich festgestellt, dass die Dinge schwieriger sind. In .NET ist beispielsweise ein Datum in einem stark typisierten Dataset (das Ihre DB-Struktur nachahmt) ein Werttyp und darf nicht null sein. Sie müssen also Problemumgehungen erstellen.

Vermeiden Sie Nullen, wenn Sie können, aber schließen Sie sie nicht aus, da sie gültige Verwendungszwecke haben.

Ich denke, Sie verwechseln die konzeptionelle Datenmodellierung mit der physischen Datenmodellierung.

Wenn ein Objekt in CDMs über ein optionales Feld verfügt, sollten Sie das Objekt subtypisieren und ein neues Objekt erstellen, wenn dieses Feld nicht null ist. Das ist die Theorie in CDMs

In der physischen Welt machen wir alle möglichen Kompromisse für die reale Welt. In der realen Welt sind NULL-Werte mehr als in Ordnung, sie sind unerlässlich

Ich stimme vielen der obigen Antworten zu und glaube auch, dass NULL gegebenenfalls in einem normalisierten Schemadesign verwendet werden kann - insbesondere dort, wo Sie möglicherweise vermeiden möchten, eine Art "magische Zahl" oder einen Standardwert zu verwenden, der dies wiederum könnte irreführend sein!

Letztlich aber, denke ich , Nutzung von null Bedürfnissen gut durchdacht werden ( und nicht durch Standard) einige der assuptions in den Antworten oben aufgeführten zu vermeiden , insbesondere dann, wenn NULL könnte angenommen werden , ‚nichts‘ oder ‚leer‘, ‚unbekannt sein 'oder der' Wert wurde noch nicht eingegeben '.

Ein Problem, wenn Sie eine Oracle-Datenbank verwenden. Wenn Sie eine leere Zeichenfolge in einer Spalte vom Typ CHAR speichern, erzwingt Oracle, dass der Wert ohne Aufforderung NULL ist. Daher kann es schwierig sein, NULL-Werte in Zeichenfolgenspalten in Oracle zu vermeiden.

Wenn Sie NULL-Werte verwenden, lernen Sie, den SQL-Befehl COALESCE zu verwenden, insbesondere bei Zeichenfolgenwerten. Sie können dann verhindern, dass NULL-Werte in Ihre Programmiersprache übertragen werden. Stellen Sie sich beispielsweise eine Person vor, die einen Vornamen, einen zweiten Vornamen und einen Familiennamen hat, aber ein einzelnes Feld zurückgeben möchte.

  SELECT FullName = COALESCE(FirstName + ' ', '') + COALESCE(MiddleName+ ' ', '') + COALESCE(FamilyName, '') FROM Person

Wenn Sie COALESCE nicht verwenden und eine Spalte einen NULL- Wert enthält , wird NULL zurückgegeben.

Technisch gesehen sind Nullen in der relationalen Mathematik, auf der die relationale Datenbank basiert, illegal. Aus rein technischer, semantischer relationaler Modellsicht sind sie also nicht in Ordnung.

In der realen Welt sind Denormalisierung und einige Verstöße gegen das Modell in Ordnung. Im Allgemeinen sind Nullen jedoch ein Indikator dafür, dass Sie Ihr Gesamtdesign genauer betrachten sollten.

Ich bin immer sehr vorsichtig mit Nullen und versuche, sie zu normalisieren, wann immer ich kann. Das heißt aber nicht, dass sie manchmal nicht die beste Wahl sind. Aber ich würde mich definitiv auf die Seite von "keine Nullen" lehnen, wenn Sie nicht wirklich sicher sind, dass es in Ihrer speziellen Basis besser ist, die Nullen zu haben.

NULL rockt. Wenn dies in einigen Fällen nicht erforderlich wäre, hätte SQL nicht IS NULL und IS NOT NULL als Sonderfalloperatoren. NULL ist die Wurzel des konzeptuellen Universums, alles andere ist NICHT NULL. Verwenden Sie NULL-Werte frei, wenn ein Datenwert möglicherweise fehlt, aber nicht übersehen wird. Standardwerte können NULL nur kompensieren, wenn sie immer absolut korrekt sind. Wenn ich zum Beispiel ein Einzelbitfeld "IsReady" habe, kann es durchaus sinnvoll sein, dass dieses Feld den Standardwert false hat und NULL nicht zulässig ist, aber dies bestätigt implizit, dass wir wissendass das, was auch immer nicht bereit ist, obwohl wir tatsächlich kein solches Wissen haben können. In einem Workflow-Szenario hat die Person, die sich für bereit oder nicht bereit erklärt, möglicherweise noch nicht die Möglichkeit, ihre Meinung einzugeben. Daher kann ein Standardwert von false tatsächlich gefährlich sein und dazu führen, dass sie eine Entscheidung übersieht, die sie anscheinend getroffen hat gemacht wurde, wurde aber in der Tat nur in Verzug gebracht.

Nebenbei bemerkt und in Bezug auf das Beispiel mit der mittleren Initiale hatte mein Vater keinen zweiten Vornamen, daher wäre seine mittlere Initiale NULL - nicht leer, Leerzeichen oder Sternchen - außer in der Armee, wo seine mittlere Initiale NMI = No Middle war Initiale. Wie dumm war das?

Technisch gesehen sind NULL-Werte als Feldwert in Ordnung, werden jedoch häufig verpönt. Abhängig davon, wie Daten in Ihre Datenbank geschrieben werden, ist es möglich (und üblich), dass im Feld ein leerer Zeichenfolgenwert anstelle eines NULL-Werts angezeigt wird. Jede Abfrage, die dieses Feld als Teil der WHERE-Klausel enthält, muss also beide Szenarien behandeln, bei denen es sich um unnötige Tastenanschläge handelt.

null bedeutet keinen Wert, während 0 dies nicht tut. Wenn Sie eine 0 sehen, kennen Sie die Bedeutung nicht. Wenn Sie eine null sehen, wissen Sie, dass es sich um einen fehlenden Wert handelt

Ich denke, Nullen sind viel klarer, 0 und '' sind verwirrend, da sie die Absicht des gespeicherten Werts nicht klar anzeigen

Nimm meine Worte nicht sarkastisch, ich meine es ernst. Wenn Sie nicht mit Spielzeugdatenbanken arbeiten, sind NULL-Werte unvermeidlich und in der realen Welt können wir NULL-Werte nicht vermeiden.

Nur um zu sagen, wie können Sie Vor-, Zweit- und Nachnamen für jede Person haben? (Zweiter Vorname und Nachname sind optional, in diesem Fall sind NULL-Werte für Sie da) und wie Sie Fax, Geschäftstelefon, Bürotelefon für alle in der Blog-Liste haben können.

NULL-Werte sind in Ordnung, und Sie müssen sie beim Abrufen ordnungsgemäß behandeln. In SQL Server 2008 gibt es ein Konzept für sparsame Spalten, bei dem Sie den für NULL-Werte belegten Speicherplatz vermeiden können.

Verwechseln Sie NULL-Werte nicht mit Nullen und anderen Werten. Die Leute sagen, dass es richtig ist.

Danke Naveen

Meine kontroverse Meinung für diesen Tag - die Standardeinstellung, NULL-Werte in Datenbankspalten zuzulassen, war wahrscheinlich die schlechteste allgemein akzeptierte Entwurfsentscheidung in allen RDBM-Ländern. Jeder Anbieter tut es und es ist falsch. NULL-Werte sind in bestimmten, spezifischen und gut durchdachten Fällen in Ordnung, aber die Idee, dass Sie NULL-Werte für jede Spalte explizit nicht zulassen müssen, macht fahrlässige Nullbarkeit weitaus häufiger als sie sein sollte.

Persönlich denke ich, dass Nullen nur verwendet werden sollten, wenn Sie das Feld als Fremdschlüssel für eine andere Tabelle verwenden, um zu symbolisieren, dass dieser Datensatz mit nichts in der anderen Tabelle verknüpft ist. Abgesehen davon finde ich, dass Nullwerte beim Programmieren der Anwendungslogik tatsächlich sehr problematisch sind. Da es in vielen Programmiersprachen für viele Datentypen keine direkte Darstellung einer Datenbank-Null gibt, wird viel Anwendungscode erstellt, um die Bedeutung dieser Null-Werte zu behandeln. Wenn eine Datenbank auf eine Ganzzahl von Null stößt und beispielsweise versucht, einen Wert von 1 hinzuzufügen (auch bekannt als null + 1), gibt die Datenbank null zurück, da auf diese Weise die Logik definiert wird. Wenn eine Programmiersprache jedoch versucht, null und 1 hinzuzufügen, wird normalerweise eine Ausnahme ausgelöst. Ihr Code wird also mit Überprüfungen übersät, was zu tun ist, wenn der Wert null ist.

Ich denke, die Frage hängt davon ab, was Sie als Wert von NULL interpretieren. Ja, es gibt viele Interpretationen für einen NULL-Wert. Einige der hier veröffentlichten Interpretationen sollten jedoch niemals verwendet werden. Die wahre Bedeutung von NULL wird durch den Kontext Ihrer Anwendung bestimmt und sollte niemals mehr als eine Sache bedeuten. Ein Vorschlag war beispielsweise, dass NULL in einem Feld für das Geburtsdatum anzeigen würde, dass die Person noch am Leben ist. Das ist gefährlich.

Definieren Sie in aller Einfachheit NULL und bleiben Sie dabei. Ich benutze es, um zu bedeuten "der Wert in diesem Feld ist zu diesem Zeitpunkt unbekannt". Es bedeutet das und NUR das. Wenn Sie möchten, dass es auch etwas anderes bedeutet, müssen Sie Ihr Datenmodell erneut untersuchen.

Es kommt alles auf Normalisierung im Vergleich zu Benutzerfreundlichkeit und Leistungsproblemen an.

Wenn Sie sich an die vollständigen Normalisierungsregeln halten, werden Sie am Ende Dinge schreiben, die wie folgt aussehen:

Wählen Sie c.id, c.lastname, ....... von Kunde aus. id = cpn2.customerid etc, etc, etc.

Es scheint, dass wenn null im Kontext des Attributs gültig ist, es erlaubt sein sollte.

Aber was bedeutet null Mittelwert ? Das ist das Problem. Es ist "kein Wert", aber es gibt ein Dutzend verschiedene Gründe, warum es dort möglicherweise keinen Wert gibt, und "null" gibt Ihnen keinen Hinweis darauf, welchen es in diesem Fall bedeutet. (Noch nicht festgelegt, für diese Instanz nicht anwendbar, für diesen Typ nicht anwendbar, nicht bekannt, nicht erkennbar, nicht gefunden, Fehler, Programmfehler, ...)

Dies ist in Java sehr häufig, wo Objektreferenzen häufig null sind.

Es gibt eine Denkschule, die besagt, dass Null-Referenzen auch dort schlecht sind . Das gleiche Problem: Was bedeutet null Mittelwert ?

IIRC, Java hat sowohl "null" als auch "nicht initialisiert" (obwohl keine Syntax für letztere). So erkannte Gosling die Torheit, "null" für jede Art von "no value" zu verwenden. Aber warum mit nur zwei aufhören ?