„Wierzę, że to niemożliwe. Nie możesz utworzyć rekordu adresu, dopóki nie znasz identyfikatora osoby i nie możesz wstawić rekordu osoby, dopóki nie znasz identyfikatora adresu dla pola PrimaryAddressId”.
Na pierwszy rzut oka twierdzenie to wydaje się tak atrakcyjne. Jest to jednak dość propostacyjne.
Jest to bardzo powszechny rodzaj problemu, który dostawcy SQL DBMS próbują zaatakować już być może od dziesięcioleci.
Kluczem jest to, że wszystkie sprawdzanie ograniczeń musi być „odroczone” do momentu zakończenia obu operacji wstawiania. Można to osiągnąć w różnych formach. Transakcje bazodanowe mogą oferować możliwość wykonania czegoś takiego jak "USTAW odroczone sprawdzanie ograniczeń na WŁĄCZONE" i gotowe (gdyby nie fakt, że w tym konkretnym przykładzie prawdopodobnie musiałbyś bardzo mocno zepsuć swój projekt, aby aby móc po prostu ZDEFINIOWAĆ dwa ograniczenia FK, ponieważ jedno z nich po prostu NIE JEST „prawdziwym” FK w sensie SQL!).
Opisane tutaj rozwiązania oparte na wyzwalaczach osiągają zasadniczo ten sam efekt, ale są narażone na wszystkie problemy związane z konserwacją, które istnieją z integralnością wymuszaną przez aplikację.
W swojej pracy Chris Date i Hugh Darwen opisują, co jest prawdziwym rozwiązaniem problemu imo:wielokrotne zadania. Zasadniczo oznacza to możliwość skomponowania kilku odrębnych instrukcji aktualizacji i zmuszenia DBMS do działania na nich tak, jakby była to jedna instrukcja. Implementacje tej koncepcji istnieją, ale nie znajdziesz żadnej, która mówi o SQL.
