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 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.
