FB: Foreign Key mit Null

[hoika]

Hallo #,

ich bin ja gerade etwas perplex.

Create Table Rechnung(RechnungsId Integer Not Null, Primary Key(RechnungsId));

Create Table RechnungsPosition(RechnungsPositionId Integer Not Null, RechnungsId Integer,
Primary Key(RechnungsPositionId));

Jetzt lege ich einen ForeignKey an

alter table RechnungsPosition
add constraint FK_RPOS
foreign key (RechnungsId)
references Rechnung(RechnungsId)


Das schlimme ist, es funktioniert !!!

Ich kann jetzt in die Tabelle RechnungsPosition Positionen eintragen,
die gar keiner Rechnung zugeordnet sind, indem ich bei RechnungsId NULL eintrage !!!

Ja, ich weiss, RechnungsId ist hier Integer, nicht Integer Not Null,
aber in meiner etwas längeren DB-Erfahrung lerne ich gerade etwas dazu.


Heiko

[DeddyH]

Und was findest Du daran ungewöhnlich? Ein ForeignKey ist ja dazu da, eine Beziehung zu einer anderen Tabelle herzustellen. Das muss aber nicht immer heißen, dass da auch Daten dahinterstecken müssen.

[Iwo Asnet]

Nun ja. Eigentlich ist es schon ungewohnt.

Aber es wird implizit (oder eigentlich fast explizit) durch die Definition "INTEGER" statt "INTEGER NOT NULL" so angegeben. Man muss nur wissen, wie man das lesen soll.

Ich persönlich vermeide das allerdings, weil ich für die Abfrage der FK-Beziehung ein LEFT JOIN nehmen müsste, was i.a. langsamer ist. Ich erzeuge mir in der Fremdtabelle dann einen leeren Datensatz, idealerweise mit der PK-ID=0. Natürlich nur, falls es notwendig ist und Sinn ergibt.

Bei Dir ist es ja so, das Rechnungspositionen ohne Rechnungen absolut katastrophal wären. Insofern sollte der FK schon als NOT NULL deklariert sein.

Bei hierarchischen Beziehungen dagegen ist es imho die einzige Möglichkeit, einen Eintrag ohne übergeordneten Vorgänger (z.B. Wurzelknoten eines Baumes) zu definieren: Hier ist der Vorgänger dann NULL. Alles andere wären Tricks (die Wurzel hat sich selbst als Vorgänger, oder ganz auf FK verzichten), die nur Probleme bereiten.

[hoika]

Hallo,

DeddyH:
Ich habe halt immer das Bsp. mit Rechnung/Rechnungsposition im Kopf,
dass da auch NULL's drinstehen können, habe ich verdrängt ;)

Ivo:
Genau so mache ich es auch immer (Not Null).
Stellenweise arbeite ich auch mit dem 0 wegen dem inner join.


Heiko

[omata]

Zitat:

Zitat von Iwo Asnet (Beitrag 1142680)

ein LEFT JOIN nehmen müsste, was i.a. langsamer ist.

Das sehe ich genau anderes herum, aber egal.

[Iwo Asnet]

bei einem LEFT JOIN ist die Engine gezwungen, die linke Tabelle durchzurennen (oder den Index)
Bei einem JOIN hat sie Möglichkeit, den kleineren Index zu nehmen.
... Aber, warte mal... Stimmt, meine Aussage war zu allgemein. Im o.g. Anwendungsfall könnte es marginal schneller sein, mit LEFT JOIN und NULL zu arbeiten, weil die Ergebnismenge kleiner ist.

[hoika]

Hallo,

zur Not ausprobieren.
Aber FB hat ja schon immer Performance-"Probleme" mit outer joins,
wobei es mit jeder Version i.d.R. besser wird.


Heiko