「これは不可能だと思います。個人のIDを知るまでは住所レコードを作成できず、PrimaryAddressIdフィールドのAddressIdを知るまでは個人レコードを挿入できません。」
一見すると、その主張はとても魅力的なようです。しかし、それはかなり厄介です。
これは、SQLDBMSベンダーがおそらく数十年にわたって攻撃を試みてきた非常に一般的な種類の問題です。
重要なのは、両方の挿入が完了するまで、すべての制約チェックを「延期」する必要があるということです。これは、さまざまな形式で実現できます。データベーストランザクションは、「SET遅延制約チェックオン」のようなことを行う可能性を提供する可能性があり、これで完了です（この特定の例では、設計を順番に非常に混乱させる必要があるという事実がない場合） 2つのFK制約を定義できるようにするためです。これは、そのうちの1つがSQLの意味で「真の」FKではないためです！）
ここで説明するトリガーベースのソリューションは、基本的に同じ効果を実現しますが、アプリケーションによって強制される整合性に存在するすべてのメンテナンスの問題にさらされます。
彼らの仕事の中で、ChrisDateとHughDarwenは、問題の真の解決策であるimoとは何か、つまり複数の割り当てについて説明しています。つまり、基本的に、いくつかの別個の更新ステートメントを作成し、それが1つのステートメントであるかのようにDBMSに作用させる可能性があります。その概念の実装は存在しますが、SQLについて話すものは見つかりません。