Erstellen einer Db-Tabelle NULL-Best Practices

Question

Nicht sicher, was die Best Practices für den Umgang mit NULL-Werten sind, wenn ich eine einzige Tabelle habe, in der zwei Felder nur teilweise ausgefüllt werden und viele NULL-Werte in den Zeilen erzeugen.

Sollten die zwei Felder in eine separate Tabelle verschoben werden, die zwei Tabellen ohne NULL-Werte erzeugt?

Ein Join über diese beiden Tabellen würde nur ein Ergebnis zurückgeben, das meiner ursprünglichen Tabelle mit den NULLs entspricht, also was ist der Sinn darin?

Scheint sinnlos, sie zu trennen, aber ich habe ein wenig darüber gelesen, Null-alles zusammen in der db zu vermeiden.

Alle Gedanken willkommen.

Answer 1

1. Rein theoretisch soll ein NULL "unbekannter Wert" bedeuten. Also - wiederum rein theoretisch - sollten Sie Ihre Tabellen so entwerfen, dass sie normalisiert werden, so dass Sie keine NULL-Werte ausfüllen müssen, um "nicht anwendbar für diese Zeile" zu bedeuten. Dieser Punkt steht jedoch praktisch in keinem Zusammenhang mit praktischen Überlegungen (Design, Leistung oder Lesbarkeit von Abfragen).

2. In der Praxis gibt es einige Leistungsaspekte. Sie sollten sehr spärliche Daten in den folgenden Fällen normalisieren weg:

   • Es materiellen Vorteil ist die Tabelle von Verkürzung (beide IO weise und/oder Raum weise). NULLs benötigen Platz, und je weiter die Zeilen, desto schlechter die Leistung. Dies ist besonders dann der Fall, wenn die Tabelle viele Zeilen enthält und es viele solcher Spalten gibt. Für einen kleineren Tisch mit nur zwei solcher Spalten sind die realisierten Vorteile möglicherweise nicht die Mühe wert, eine zusätzliche Verbindung zu haben.

   • Ihre Abfragen haben die betreffende Spalte in der WHERE-Klausel. IIRC, die Abfrage einer stark NULL-Spalte ist ziemlich ineffizient.

   • Auf der anderen Seite kann die Optimierung von Joins in der Abfrage die Leistung des Optimierungsprogramms beeinträchtigen (zumindest bei Sybase, wenn Ihre Joins 10 + Tabellen enthalten), da CPU-Ressourcen belegt werden, wenn das Optimierungsprogramm ausgeführt wird verwirrend den Optimierer, um einen SEHR schlechten Plan auszuwählen). Die Lösung besteht darin, zu viele Tabellen aufgrund von Normalisierung zu vermeiden (z. B. keine Aufteilung der 2 Spalten in eine separate Tabelle) oder den Abfrageplan zu erzwingen. Letzteres ist offensichtlich Bad Juju.

Answer 2

Nulls verursachen falsche und widersprüchliche Ergebnisse in Abfragen und in der Regel die Komplexität des Codes durch die spezielle Handhabung in Code benötigt, die sie verarbeiten muss erhöhen. Aus diesen Gründen ist es normalerweise sinnvoll, Nullen in Ihren Datenbankentwürfen zu vermeiden oder zu minimieren. Sie müssen auch keine Nullen in Abfragen verwenden, obwohl SQL sie leider sehr schwierig zu vermeiden macht. Wenn Sie jedoch keine Nullen in Basistabellen verwenden, stellen Sie sicher, dass Ihr Datenmodell die Realität besser widerspiegelt, und Sie geben den Datenbankbenutzern mehr Kontrolle darüber, wie Nullen verwendet werden sollen.

Answer 3

Wie dportas in einem Kommentar schon sagt, ist es hilfreich zu wissen, was ein null Wert in einem bestimmten Bereich bedeutet - nicht das, was es in der Theorie bedeutet, aber was es bedeutet, in Ihre Daten.

Ich denke, solange man klar ist, was ein null in der Tabelle bedeutet, und wenn Sie sicher sind, es bedeutet nur eine Sache, Sie eine fundierte pragmatische Entscheidung darüber, ob es ermöglichen, machen kann.

Meinung: Meine Faustregel ist, dass NULL festlegbare Felder sind in Ordnung, aber nicht Multi-Task

Answer 4

Nulls sind entscheidend in einer Datenbank zu haben. Ich habe mich noch nie mit einer Datenbank beschäftigt, die Nullen nicht erlaubt, die am Ende nicht viel schwieriger zu hinterfragen war, viel schwieriger zu pflegen (wie entscheidest du, welcher Wert bedeutet, dass ich die Antwort nicht weiß) und normalerweise mehr schlechte Daten. Ja, Nullen erfordern eine spezielle Behandlung in Abfragen, also fügen Sie beispielsweise ein viel späteres Datum (1.1.1999) als Enddatum hinzu, um zu vermeiden, dass Sie eine Null haben.

Die Wahrheit ist, einige Daten sind gerade nicht bekannt, als der Datensatz eingefügt wird. Es gibt keinen Ersatz für null.

Nun, in Ihrem Fall, wo Sie auf zwei Tabellen ausbrechen sollten, hängt viel von der Breite der Tabellen und der Häufigkeit ab, die Sie benötigen, um diese Nullable-Abfragen abzufragen. Ich würde wahrscheinlich nicht eine zweite Spalte in eine andere Tabelle verschieben, obwohl ich viele Nullen hatte, weil sie immer mit den anderen Informationen in der Basistabelle abgefragt wird. Es wäre auch unwahrscheinlich, dass ich eine Enddatumsspalte verschieben würde. Aber wenn die Spalten Dinge waren, die man gut kennt, die man normalerweise nicht abfragt, wenn man die Basisdaten abfragt (wie Geburtstag, Haarfarbe, etc.), dann kann eine gesonderte Tabelle nur für die Datensätze, die die Daten enthalten, in Ordnung sein. Denken Sie jedoch daran, wenn Sie abfragen, ob Sie einen inneren Join verwenden, eliminieren Sie alle Datensätze, die keinen Wert in der zweiten Tabelle haben. Wenn ich normalerweise alle Datensätze haben möchte (wie mit dem zweiten Vornamen, frage ich nur selten Leute mit dem zweiten Vornamen 'Mary'), dann neige ich dazu, sie in der gleichen Tabelle zu behalten, es sei denn, der Tisch wird sehr breit und ich Normalerweise möchten Sie diese Informationen nicht abfragen.