„Вярвам, че това е невъзможно. Не можете да създадете адресен запис, докато не знаете идентификационния номер на лицето и не можете да вмъкнете записа на лицето, докато не знаете AddressId за полето PrimaryAddressId.“
На пръв поглед това твърдение изглежда ТОЛКОВА привлекателно. Въпреки това е доста благоприятно.
Това е много често срещан вид проблем, който доставчиците на SQL СУБД се опитват да атакуват вече може би десетилетия.
Ключът е, че всички проверки на ограничения трябва да бъдат "отложени", докато и двете вмъквания не бъдат направени. Това може да се постигне под различни форми. Транзакциите в базата данни могат да предложат възможността да направите нещо като "SET deferred constraint checking ON" и сте готови (ако не беше фактът, че в този конкретен пример, вероятно ще трябва да се забърквате много с вашия дизайн, за да за да можете просто да ДЕФИНИРАТЕ двете FK ограничения, защото едно от тях просто НЕ Е „истински“ FK в смисъла на SQL!).
Решенията, базирани на тригери, както е описано тук, постигат по същество същия ефект, но те са изложени на всички проблеми с поддръжката, които съществуват с целостта, наложена от приложението.
В работата си Крис Дейт и Хю Даруен описват какво е истинското решение на проблема:множествено възлагане. Това по същество е възможността да се съставят няколко отделни оператора за актуализиране и СУБД да действа спрямо него, сякаш това е един единствен оператор. Реализации на тази концепция наистина съществуват, но няма да намерите такива, които говорят SQL.
