Grund, keine nullbaren Zahlen in Oracle zu verwenden?

Unsere Firma hat eine Schnittstelle zu einer anderen Softwarefirma für ein gemeinsames Projekt, und uns wurde mitgeteilt, dass wir, wenn ein bestimmter Wert nicht angezeigt werden soll, einen Wert von -5000 (ihren willkürlichen Sentinel-Wert) übergeben sollen. Der Grund dafür ist, dass keine Zahlenspalte in ihrer Oracle-Datenbank auf Empfehlung ihres (jetzt ehemaligen) Oracle-Entwicklers Nullwerte unterstützt. Diese Firma schreibt auch den größten Teil ihres Codes in VB6 (langsam Übergang zu VB.NET, ein anderes Thema für einen anderen Tag ...). Gibt es aus reiner Neugier einen triftigen Grund für diese Empfehlung? Mir fällt nichts ein.

--- bearbeiten

Danke für das Feedback an alle. Ich habe die gleiche Frage auf CodeProject.com ( Link ) gestellt und sehr ähnliche Rückmeldungen erhalten. Es scheint, dass das einzige Mal, an dem man anfangen könnte, diese Praxis zu rechtfertigen, mit Fremdschlüsseln zusammenhängt, und ich kann feststellen, dass sie nirgendwo im System Fremdschlüssel verwenden. Der Entwickler, der diese Entscheidung getroffen hat (ich habe früher in diesem Unternehmen gearbeitet), verfügt über erheblich mehr Erfahrung als ich. Deshalb wollte ich sicherstellen, dass es keinen gültigen Grund dafür gibt, bevor es zu einer Verspottung kommt.

Realistisch ist die Anforderung verrückt. Wie alle großen verrückten Ideen basiert es jedoch wahrscheinlich auf einem Nugget potenzieller Vernünftigkeit, das von Menschen, die die zugrunde liegenden Gründe nicht verstehen, weit aus dem Kontext gerissen wurde.

Es kann sinnvoll sein, ein Datenbankschema so zu gestalten, dass keine NULLWerte zulässig sind. In diesem Fall wird jedoch ein Normalisierungsgrad festgelegt, bei dem jedes nicht erforderliche Element in eine separate Tabelle mit einem entsprechenden Fremdschlüsselverweis zurück zum übergeordneten Element aufgeteilt wird. Es wird in der Praxis nicht oft gemacht, aber in Fällen, in denen es sinnvoll ist, kann es Vorteile geben.

Wenn Sie ein Datenbankschema so entwerfen, dass no NULL Werte zulässig sind, ist es nicht sinnvoll, magische Werte zuzulassen, um anzuzeigen, dass etwas unbekannt ist. Das führt zu allen Problemen, die das Zulassen von NULLWerten mit sich bringt, und fügt zusätzlichen Code hinzu, um nach den magischen Werten zu suchen, die überall wiederholt werden müssen. Es macht keinen Sinn, eine API zu entwickeln, die die Übergabe magischer Werte unabhängig vom Datenbankdesign erfordert. Wenn Sie Ihren Code mit Überprüfungen auf magische Werte humpeln, sollten Sie diesen Wahnsinn wirklich nicht auf andere Systeme ausbreiten lassen .

Es gibt keinen gültigen Grund , einen magischen Wert anstelle von NULL zu verwenden. Dies könnte der Denkprozess von jemandem sein, der dieses Chaos verursacht. Sie schreiben so etwas:

 SELECT c1, c2 FROM t1 WHERE c3 < 30;

Wenn dies nicht die erwarteten Ergebnisse zurückgibt, stellen sie fest, dass es keine NULL-Werte enthält und Folgendes schreiben müsste:

SELECT c1, c2 FROM t1 WHERE c3 < 30 OR c3 IS NULL;

Sie möchten dies in Zukunft nicht mehr schreiben oder vergessen, also haben sie die Lösung gefunden, alle NULLS -5000 zu machen. Magischerweise behandelt ihre ursprüngliche Abfrage NULL-Werte ohne Änderungen. Was sie nicht erkennen, ist, dass jetzt jemand, der diese Werte ausschließen möchte, Folgendes schreiben muss:

SELECT c1, c2 FROM t1 WHERE c3 < 30 AND c3 <> -5000;

Oder wenn sie diese Werte wollten und einen höheren Bereich suchen:

SELECT c1, c2 FROM t1 WHERE c3 > 40 OR c3 = -5000;

Sie können auch nicht erkennen, dass das Folgende nicht mehr sinnvoll wäre:

SELECT c1, c2 FROM t1 WHERE c3 IS NULL;

Stattdessen muss sich eine Person an den magischen Wert erinnern. Mit jedem verwendeten Datentyp müssen sie sich weitere magische Werte merken, z. B. 1/1 // 1900, "Z", -5000. Wenn der magische Wert in den Daten enthalten ist, müssen sie sich außerdem an alternative magische Werte erinnern.

Für einen bestimmten Fall vereinfacht dies den Code auf Kosten anderer Fälle, ganz zu schweigen von Speicherplatz, Indexgröße, Analyse von Abfragen, Konsistenz usw.

Es ist völliger Wahnsinn und es gibt keine Rechtfertigung dafür. NULLwurde erstellt, um das Fehlen eines Werts darzustellen und um einen tatsächlichen Wert wie -5000 zu verwenden, ist bonkers.

Normalerweise würde ich so kurz keine Antwort schreiben, aber die Frage verdient es, eine der sichtbarsten auf dba.se zu sein. Je mehr Antworten, desto besser.

Ich habe ein bisschen darüber nachgedacht, um zu versuchen, positiv zu sein und die Notwendigkeit zu rechtfertigen, einen beliebigen Wert anstelle einer Null zu verwenden, und es scheint (zumindest für mich) keinen gültigen Grund dafür zu geben, außer vielleicht in einem geschlossenen Data-Mining-Datensatz um die Leistung und Abfragen zu verbessern und zu vereinfachen, und zwar nur in Fällen, in denen die Zahlen keine Werte sind, die die Daten verzerren könnten. Auch dies müsste sorgfältig abgewogen werden. In allen Situationen der realen Welt ist es keine gute Praxis, Null zu bewerten. Dadurch wird eine NOT NULL-Spaltendefinition von Ihrem Freund an Ihren Feind weitergegeben, da dies nicht der Fall ist.

Es ist etwas ganz anderes zu sagen, dass unsere Anwendung für einige (oder sogar alle) Spalten keinen NULL-Wert akzeptieren sollte. Dies ist eine vernünftige und bewährte Vorgehensweise, und es gibt gut dokumentierte Vorteile, wenn Nullen nicht zugelassen werden (z. B. Schlüssel und Indizes und statistische Berechnungen). Das Zuweisen eines Werts für "An der Stelle einer Null sitzen" ist jedoch keineswegs gleich. Dies ist die Rute für Ihren eigenen Rücken, da Sie zuerst einen Wert auswählen müssen, der niemals verwendet wird. Filtern Sie diesen Wert wie die Null heraus und denken Sie daran, ihn nicht in Berechnungen und Zusammenfassungen zu verwenden und ihn aus externen Datenfeeds zu entfernen . Dies ist mindestens genauso schlimm, wenn Sie eine Null verwenden, um einen tatsächlichen Wert darzustellen, was Sie sich selbst mitteilen, aber nicht.

Die meisten Probleme, die durch Nullen verursacht werden, können behoben werden (bessere Normalisierung, funktionsbasierte Indizes, Bitmap-Indizes oder ein einfaches WHERE x IS NOT NULL). Glauben Sie, dass bei einigen großen Telekommunikationsunternehmen oder bei Amazon in der monatlichen Leistungsbesprechung ein DBA diesen großartigen Plan umreißt, um die Abfragen ihrer enormen Datensätze ein wenig zu beschleunigen, indem Sie null durch einen beliebigen Wert ersetzen, etwa -5000 oder was auch immer - Ich bin offen für den Wert ... ". Oder glauben Sie, dass sie ihre Zeit zwischen einem besseren Anwendungsdesign, um unerwünschte Nullen herauszufiltern, und einer Abfrageoptimierung auf der Grundlage der tatsächlich erhaltenen Daten aufwenden ? OK, in Ordnung, vielleicht ist ein monatliches Treffen ein bisschen optimistisch, aber wenn es passiert, kann ich Ihnen versichern, dass "Ersetzen von Nullen durch -5000 (oder was auch immer) für eine bessere API" kein Tagesordnungspunkt ist.

Für mich ist es in Ordnung zu sagen, dass ich fehlende Daten nicht akzeptiere (Sie müssen ein Alter oder einen Preis oder einen Regionalcode oder was auch immer haben) und manchmal sogar in Ordnung zu sagen, dass für diese Spalte ein Standardwert eingegeben wird, wenn du legst nichts anderes. Es ist nicht in Ordnung, einen Wert auf null zu setzen. Denken Sie als Beispiel an Felder mit mittlerem Namen. Manchmal existieren diese nicht, da die Eltern zu faul sind, um alle Felder auszufüllen. Fügen wir unseren Daten "keine" oder "fehlende" oder "unbekannte" hinzu, um unsere Suche zu verbessern? Nein, weil es seltsame Personen geben kann, die ihre Namen in diese Werte ändern. Wenn wir die Daten ausdrucken, wissen wir nicht, ob wir sie aufnehmen müssen oder nicht. Es ist ein einfaches, aber weitreichendes Beispiel. Wir kennen NULL und haben vorhersehbare eingebaute Funktionen, um damit umzugehen. Sie können dies nicht besser codieren.

Wenn keine Antwort (oder NULL) keine gültige Antwort auf Ihre Eingabeanforderung ist, lassen Sie sie in der Anwendung oder in der Datenbank nicht zu. Wenn es sich um eine gute Antwort handelt, müssen Sie sie sowohl in Ihrer Anwendung als auch in Ihrer Datenbank zulassen und bearbeiten es als gültige Antwort. Wenn es Teil einer Reihe gültiger Antworten ist, muss Ihre Datenbank so konzipiert sein, dass sie diese speichert. Schließlich sagt man nicht hey, Zahlenfelder sind so langweilig, dass man Zahlen in Blobs speichern und Bilder von wilden Tieren verwenden kann, um jede Zahl darzustellen, denn das ist verrückt (cool, aber verrückt). Wir entscheiden auch nicht, dass uns der Buchstabe B nicht gefällt, und ersetzen ihn wie ein grausamer Albtraum in der Sesamstraße durch ein # in unseren Daten. Wenn B keine Antwort ist, die wir wollen, sagen wir dem Benutzer "Hey, du kannst hier kein B setzen". Warum also null anders behandeln?

Vermeiden Sie also Nullen, die Sie auf Anwendungsebene nicht möchten, und bearbeiten Sie sie in Ihrer Datenbank, wo Sie sie ansonsten akzeptieren, so sicher wie giraffe + giraffe = hippo, dass Ihre sinnlosen Datenprobleme Sie in Schwierigkeiten bringen.