[SQL] problematische NULL-Wete

[Hansa]

Hi,

ich habe hier Ärger mit den NULL-Werten in meiner DB. Wie es aussieht sollte man die wohl besser gänzlich vermeiden, wenn es denn geht. Da ich einen BI-Trigger verwende, um die ID zu erhalten habe ich mir überlegt, daß wohl nichts dagegen spricht, auch die anderen Felder mit 0 (eben nicht mit NULL) oder mit ' ' (Blank) vorzubesetzen. Oder ist das doch nicht so gut ?

[r_kerber]

Moin Hansa,

das geht IMHO nur gut, wenn die Zahl 0 keine Bedeutung hat. Es ist schon ein Unterschied zwischen 0 und "nicht definiert". Du mußt dies also von Fall zu Fall entscheiden!

[nieurig]

und ...
bei richtig dynamischer Verwaltung der Daten dürfte der Speicherverbrauch etwas geringer sein (wenn es denn interssiert :wink: )

Man kann sich sonst nur zur Regel machen alle Felder in denen NULL vorkommen kann für Vergleiche usw. mit Hilfe von Funktionen definiert umzuwandeln.
bei Access z.B. via nz(Feldname,"")

Aber man vergißt es eben gern.
Niels

[Robert_G]

Zitat:

Zitat von Hansa

Oder ist das doch nicht so gut

Jupp, das ist nicht so gut.

Stelle dir vor, du hast zwei Foreign Keys von Tabelle A auf Tabelle B & C, sagen wir A_B und A_C.
Wenn du zwar in A einen DS hast, der B referenziert, aber NICHT C, könntest du ganz einfach das Feld A_C leer lassen. Bei einer 0 wird er dir auf's Dach steigen, da du in C wohl keine 0 als PK hast.

Das NULL-Problem lässt sich oftmals ganz esay über die Funktion nvl lösen.
Ist der erste Parameter NULL, wird der zweite ausgegeben.

SQL-Code:

SELECT A.IrgendWas
      ,B.IrgendWas
      ,C.IrgendWas
FROM  A, B, C
WHERE nvl(A.A_B, -1) = B.PK(+) AND
      nvl(A.A_C, -1) = C.PK(+)

Aber Vorsicht: Bei manchen DBs versagt die Indexierung, wenn man über das Ergebnis einer Funktion verknüpft.

Wenn du aber _weißt_ (nicht glaubst ;) ), dass die FKs nie leer sind, würde ich eine NOT NULL Constaraint an die Spalte hängen.
Dieses "Default 0" halte ich persönlich für Unsinn. Bei Feldern, die keine anderen Tabellen referenzieren, oder die keine "wichtigen" Daten enthalten (zum Bleistift der Vor- & Zuname in einer Kontakttabelle sollten auch NOT NULL sein) können doch auch leere Werte rein. (Die wirst du wohl auch nicht benutzen, um Tabellen in einer Abfrage zu verknüpfen, dafür hast du ja die Schlüssel).

Zitat:

Zitat von nieurig

bei richtig dynamischer Verwaltung der Daten dürfte der Speicherverbrauch etwas geringer sein (wenn es denn interssiert )

Sorry, aber ich kapiere da den Zusammenhang zu Hansas Problemchen nicht. :gruebel:

[Hansa]

Das Problem stellte sich so heraus, daß mit folgender Konstruktion keine Daten zurückgeliefert wurden :

Delphi-Quellcode:

SELECT * FROM RECHNUNG WHERE ID_ART = :ID_ART AND ID_KUNDE = :ID_KUNDE

Der Standard ist jedoch, daß der Parameter ID_KUNDE in 95% der Fälle nicht gebraucht wird. Die DB hat in diesen Fällen NULL genommen und deshalb schlug das SELECT fehl. Ich habe deshalb vor, zu jeder Tabelle einen 0-ten Datensatz (also alles 0 oder ' ') anzulegen und dessen Werte für die Referenzen zu nutzen. Dann wären keine NULL-Werte mehr da.

[shmia]

Zitat:

Zitat von Hansa

Das Problem stellte sich so heraus, daß mit folgender Konstruktion keine Daten zurückgeliefert wurden :

Delphi-Quellcode:

SELECT * FROM RECHNUNG WHERE ID_ART = :ID_ART AND ID_KUNDE = :ID_KUNDE

Der Standard ist jedoch, daß der Parameter ID_KUNDE in 95% der Fälle nicht gebraucht wird. Die DB hat in diesen Fällen NULL genommen und deshalb schlug das SELECT fehl. Ich habe deshalb vor, zu jeder Tabelle einen 0-ten Datensatz (also alles 0 oder ' ') anzulegen und dessen Werte für die Referenzen zu nutzen. Dann wären keine NULL-Werte mehr da.

Das würde ich nicht tun. Besser so:

SQL-Code:

SELECT * FROM RECHNUNG WHERE ID_ART = :ID_ART AND (ID_KUNDE = :ID_KUNDE OR ID_KUNDE IS NULL)

NULL-Werte sind dazu da, verwendet zu werden, wenn keine Information über den Inhalt eines Feldes vorhanden ist. Natürlich muss man seine Abfragen auf die Gegebenheiten abstimmen.

[nieurig]

@Robert_g

Zitat:

Sorry, aber ich kapiere da den Zusammenhang zu Hansas Problemchen nicht.

Hatte nichts mit seinem Problem zu tun aber mit der Überlegung auf Null-Werte zu verzichten um keine Probleme zu haben.

Ich bin ebenfalls der Meinung, dass das Ersetzen der Nullwerte inhaltlich schlechter ist als die Null-Werte im Datensatz zu speichern. In einigen Fällen könnte das auch ein Beitrag zur Reduzierung des Speicherbedarfes in der Datenbank sein.

Zitat:

Das NULL-Problem lässt sich oftmals ganz esay über die Funktion nvl lösen.

Das ist eben DB abhängig.
Wie ich schon sagte, müßte man bei Access

SQL-Code:

nz()

verwenden.
Beim MSSQL-Server heißt die Funktion

SQL-Code:

isnull()

usw.

Niels

Edit: Fehler behoben