[SQL] lus van foreign keys

[Verwijderd]

Hoi,

Ik vraag me iets af Stel je hebt 2 tabellen (A en B ), met dus hun eigen primary key (a en b). Stel nu dat een kolom in A (x) een foreign key is naar b en een kolom in B een foreign key is naar a. Je begint met A en B zijnde lege tabellen.

-> je kan niets in A inserten, want B is nog altijd leeg, dus de foreign key x (in A) kan nooit voldaan zijn?
-> je kan niets in B inserten, want A is nog altijd leeg, dus de foreign key y (in B ) kan nooit voldaan zijn?

Volgens mij snap ik iets niet goed ivm. foreign keys, want imo is dit absurd Of is dit echt zo? (en moet je dus eerst de fk's droppen en achterna terug activeren)

ps: volgens mij maakt het niets uit volgens welke policy (null, cascade en die andere - kan niet op naam komen -) de foreign keys gedefinieerd zijn.

[ Voor 9% gewijzigd door Verwijderd op 13-06-2004 23:59 ]

[mjax]

Wederzijdse foreignkeys los je normaal gesproken met een koppeltabel op. A heeft een 1:N relatie met de koppeltabel en B ook.

In dit geval bevatten A en B geen foreignkeys meer, maar zitten in de koppeltabel de twee door jou genoemde foreignkeys. Zo kun je natuurlijk wel aan je foreignkey constraints voldoen, want er is maar 1 tabel waarvoor ze gelden.

[ Voor 57% gewijzigd door mjax op 14-06-2004 00:03 ]

[zeroxcool]

Dubbele foreign keys zijn inderdaad N:M relaties wat leidt tot een koppeltabel met beide attributen (of identifiers) van A en B erin.

[Verwijderd]

Ach ja, tuurlijk! Als je zo'n lus van foreign keys hebt, zijn je tabellen nooit in normaalvorm!

bedankt voor de snelle tip mjax en ZeRoXcOoL

[ Voor 8% gewijzigd door Verwijderd op 14-06-2004 00:12 ]

[Soultaker]

Voor dit soort dingen heb je ook transacties. Constraints worden doorgaans alleen geforceerd tussen afzonderlijke states van de database. Door twee insert operaties door middel van een transactie als een atomaire operatie uit te voeren kun je dus prima aan de constraints voldoen: de database state halverwege de transactie is niet zichtbaar en zowel ervoor als erna wordt aan de constraints voldaan.

[NMe]

Slightly offtopic:
"Rondlopen" in je ERD/ander schema is bijna altijd slecht. Ook als er 3 tabellen zijn. Ter illustratie:
Je hebt tabel 1 die een FK heeft in tabel 2, en tabel 2 heeft weer een FK in tabel 3. Dan is het nogal nutteloos om in tabel 3 nog een FK op te nemen naar 1, je kan immers ook via tabel 2 de relatie volgen.
Natuurlijk gaat dit verhaal ook op bij meerdere tabellen.

[Verwijderd]

okédoké, ik snap het voor de volle 100% nu

bedankt nog NMe84 en Soultaker!

[Verwijderd]

Soultaker schreef op 14 juni 2004 @ 00:35:
Voor dit soort dingen heb je ook transacties. Constraints worden doorgaans alleen geforceerd tussen afzonderlijke states van de database. Door twee insert operaties door middel van een transactie als een atomaire operatie uit te voeren kun je dus prima aan de constraints voldoen: de database state halverwege de transactie is niet zichtbaar en zowel ervoor als erna wordt aan de constraints voldaan.

Deze logica klopt volgens mij niet.
De database dient na elke losse actie al in een consistente staat te zijn.

Na het afsluiten van de transactie dient de applicatielogica in de database consistent te zijn.

[jochemd]

Soultaker schreef op 14 juni 2004 @ 00:35:
Voor dit soort dingen heb je ook transacties. Constraints worden doorgaans alleen geforceerd tussen afzonderlijke states van de database. Door twee insert operaties door middel van een transactie als een atomaire operatie uit te voeren kun je dus prima aan de constraints voldoen: de database state halverwege de transactie is niet zichtbaar en zowel ervoor als erna wordt aan de constraints voldaan.

Precies andersom. Er moet per default na elk statement aan alle constraints voldaan worden, de uitzondering is wanneer een constraint is gedefinieerd als DEFERRED, dan wordt hij pas bij transactie commit gecontroleerd.