Frage zu 1:1 Beziehung

[Frickler]

Ich habe eine Tabelle, zu der es eine weitere Tabelle in einer Art 1:1 Beziehung gibt. Nicht zu jedem Datensatz der Haupttabelle gibt es einen Eintrag in der Nebentabelle, aber zu einigen. Und es ist immer genau einer. Dass das mal mehr werden, kann ich aus der Struktur der Daten absolut ausschließen.

Bei so einer Verbindung brauchts in der Nebentabelle keine Trennung zwischen PK und FK, sondern der PK ist gleichzeiting auch der FK.

Jetzt meine Frage: ist es sinnvoll, die FK-Beziehung quasi umzudrehen? Also statt einen FK in der Nebentabelle den FK in der Haupttabelle unterzubringen? Ist der ungleich NULL, zeigt er auf den Eintrag in der Nebentabelle (die dann natürlich einen eigenen PK hat). Der Vorteil, den ich da sehe, wäre halt, dass ich auf einen Blick (ohne separate Abfragen oder Joins) sehen kann, ob es einen Eintrag in der Nebentabelle gibt; ist der FK NULL, gibts keinen, ist er NOT NULL, gibts einen.

[DeddyH]

Das hätte aber den Nachteil, dass man nicht mehr über eine einfache Löschregel (ON DELETE CASCADE) die Detaildatensätze automatisch löschen kann, wenn man den Masterdatensatz löscht.

[mkinzler]

Ich bin kein Freund von Löschregeln. Ich würde aber trotzdem die Master/Detail-Beziehung nicht umkehren. Abzufragen ob ein 0 dürfte von der Performance her auch nicht schneller sein als ein Join.

[jobo]

Es wäre ein "ungewöhnlicher" Ansatz. Läuft einem vielleicht mal in die Hacken (oder Kollegen)
Was das "direkt sehen, dass .." angeht:
Sprichst Du hier wirklich von Sehen oder von Prüfcode in Delphi?
Falls Du der DB etwas Arbeit sparen willst, es ist quasi eine ganz normale Aufgabe auf einem (sowieso indizierten) PK nach Existenz zu schauen oder zu joinen.

P.S.: Löschregeln finde ich auch problematisch wie mkinzler.

[hoika]

Hallo,
die Frage ist, wie oft braucht man diese Information und wie oft andere.
Danach richte ich immer meine Datenstruktur aus in der Hoffnung, dass sich nicht groß was ändert.

Ich würde das nicht machen, eben weil mal ein Kollege nicht erwartet, dass bei genau diesen Tabellen alles anders rum gesetzt ist.

[jobo]

Nachtrag:
Mglw. hast Du ja im jetzigen Hauptdatensatz bereits Infos, die eigentlich bereits abbilden, dass es Detaildaten geben muss. Die könntest Du zum "Sehen" dann nutzen. Ggf. kannst du das auch explizit modellieren und wie bei den Persitenzsystemen eine Spalte für diese Info spendieren. Dazu kann man dann auch wieder einen Constraint anlegen, der das überwacht.
Alternativ noch eine Bastelvariante: eine "zentrale"(oft gebrauchte) Spalte aus der neuen Detailmenge in die Originalmenge aufnehmen. Die liefert dann durch Existenz (not null) den Indikator. (verbraucht immer noch weniger Platz (oder gleichviel, je nachdem) als eine Reverse FK)

[dataspider]

Ich sehe keine Notwendigkeit, das Schema so zu verbiegen.

Man kann für die Haupttabelle immer noch eine View erzeugen, welche die Information liefert.
Will man keine View, dann kann man in der Haupttabelle auch ein berechnetes Feld (select first 1 id from Detail) anlegen.

Egal, ob man von Löschregeln etwas hält oder nicht.
Man muss sich ja nicht die Möglichkeiten verbauen, wenn man es dann doch mal braucht.

Frank

[Frickler]

Danke für Eure Hilfe.

Obwohl ich inzwischen alle Programme umgestellt habe, kommt zuweilen noch die BDE-Denke durch, JOINs möglichst zu vermeiden wegen Bremseffekt... :)

[hoika]

Hal,
ne, das lag nicht an der BDE direkt, sondern am local SQL.
Ich hatte damals die BDE und Interbase, da war der Join schön schnell.