"Jeg tror, det er umuligt. Du kan ikke oprette en adressepost, før du kender personens ID, og du kan ikke indsætte personposten, før du kender et adresse-id for feltet PrimaryAddressId."
Umiddelbart virker den påstand SÅ tiltalende. Det er dog ret uhyggeligt.
Dette er et meget almindeligt problem, som SQL DBMS-leverandørerne har forsøgt at angribe i måske årtier allerede.
Nøglen er, at al kontrol af begrænsninger skal "udskydes", indtil begge indsættelser er udført. Det kan opnås under forskellige former. Databasetransaktioner kan give mulighed for at gøre noget som "SET deferred constraint checking ON", og du er færdig (var det ikke for det faktum, at du i dette særlige eksempel sandsynligvis ville skulle rode meget hårdt med dit design for at at være i stand til bare at DEFINERE de to FK-begrænsninger, fordi den ene af dem simpelthen IKKE ER en 'ægte' FK i SQL-forstand!).
Trigger-baserede løsninger som beskrevet her opnår i det væsentlige den samme effekt, men de er udsat for alle de vedligeholdelsesproblemer, der findes med applikationspåtvunget integritet.
I deres arbejde beskriver Chris Date &Hugh Darwen, hvad der er den sande løsning på problemet:multiple assignment. Det vil i det væsentlige sige muligheden for at sammensætte flere forskellige opdateringssætninger og få DBMS til at handle efter det, som om det var en enkelt erklæring. Implementeringer af dette koncept findes, men du vil ikke finde nogen, der taler SQL.