Fremdschlüssel auf Primärschlüssel der eigenen Tabelle

[tklustig]

Hallo, folgender SQL-Code erstellt u.a. einen Fremdschlüssel auf den Primärschlüssel der eigenen Tabelle. Was soll das bringen? Was haben sich die Entwickler dabei gedacht? Kenne die Referenzierung nur auf die Primärschlüssel anderer Tabellen.

CREATE TABLE `product` (
  `id` binary(16) NOT NULL,
  `version_id` binary(16) NOT NULL,
  `parent_id` binary(16) DEFAULT NULL,
  `parent_version_id` binary(16) DEFAULT NULL);

ALTER TABLE `product`
  ADD PRIMARY KEY (`id`,`version_id`),
  ADD KEY `fk.product.parent_id` (`parent_id`,`parent_version_id`);
 
  ALTER TABLE `product`
  ADD CONSTRAINT `fk.product.parent_id` FOREIGN KEY (`parent_id`,`parent_version_id`) REFERENCES `product` (`id`, `version_id`) ON DELETE CASCADE ON UPDATE CASCADE;
COMMIT;

 

[Zvoni]

Genau anderst herum:
Whisky Cola hat keinen Eintrag in FK. Dort also NULL
Whisky und Cola jeweils haben einen Eintrag "3" im FK (um bei deinen ID'S zu bleiben)

EDIT: Mir ist klar, das das Beispiel eigentlich Murks ist, da beim "Getränke"-Szenario du ja definitiv ein "m:m"-Szenario hast (Cola wird in Whisky Cola verwendet als auch in Cuba Libre).

Ich glaube das bessere Beispiel ist oben die "Geburtsstation im Krankenhaus" oder der PC-Laden.

Um das jetzt auch zu Ende bekommen:
FK auf PK der eigenen Tabelle ist ein gültiges und auch gängiges Verfahren in nur einer Datenbank-Tabelle eine Hierarchie-Struktur abzubilden.

Wie gesagt: In dem Code den du in Post 1 gezeigt hast, hat mich am meisten der ON DELETE CASCADE überrascht, aber dazu habe ich dir ja auch ein Beispiel genannt (PC-Laden)

 

[Zvoni]

Jetzt ist mir doch noch ein Szenario eingefallen:
"Vorgänger-Modell"/"Nachfolge-Modell"

Produkte
ID - Bezeichnung - FK
1 - Urmodell - NULL --> wird 6 Monate lang verkauft
2 - Nachfolger1 - 1 --> ID=1 gilt als veraltet, und wird mit ID=2 ersetzt. Hat wiederum eine Lebenszeit von 6 Monaten
3 - Nachfolger2 - 2 --> ID=2 gilt jetzt als veraltet und wird mit ID=3 ersetzt
usw.....


oder sowas (Buchladen)
ID - Bezeichnung - FK
1 - Bibel (lateinisch) - NULL
2 - Bibel (engl. Übersetzung) - 1
3 - Bibel (dt. Übersetzung) - 1
//ID=2 und ID=3 verweisen auf ID=1
4 - Bibel (schweizer Übersetzung) - 3 //verweist auf ID=3
5 - Bibel (US-engl. Übersetzung) - 2 //verweist auf ID=2
6 - Bibel (dt. Übersetzung - korrig. Fassung) - 1 //verweist auf ID=1

und der ON DELETE CASCADE hätte jetzt folgende Wirkung:
Wenn du entscheidest, die Bibel (lateinisch) zu löschen, weil du das eben nicht mehr im Buchladen verkaufen willst, fliegen alle anderen mit raus!

 

[tklustig]

Okay. Wenngleich sich mir der Sinn erst jetzt so einigermaßen erschließt:
Das Beispiel ist, man höre und staune, der aktuellen Datenbank von Shopware6 genau so entnommen, wie ich es gepostet habe. Shopware6 ist mit dem PHP Framework Symfony geschrieben und derart konfus in allem, was mir jemals untergekommen ist. Unter der URL:
Wie ist das möglich...?
habe ich dbzgl. eine weitere Kuriosität gepostet. Danke für Deine Hilfe!

 

[Zvoni]

Zur Veranschaulichung hab ich mal ne SQL-Fiddle gemacht
DB Fiddle - SQL Database Playground

In dem Fiddle:
Wenn du jetzt z.Bsp. das derzeit "gültige" Modell suchen willst, würdest du einfach eine WHERE-Klausel machen "T2.Description IS NULL"
DB Fiddle - SQL Database Playground