"Je crois que c'est impossible. Vous ne pouvez pas créer d'enregistrement d'adresse tant que vous ne connaissez pas l'ID de la personne et vous ne pouvez pas insérer l'enregistrement de personne tant que vous ne connaissez pas un AddressId pour le champ PrimaryAddressId."
À première vue, cette affirmation semble tellement attrayante. Cependant, il est assez proposant.
Il s'agit d'un type de problème très courant auquel les fournisseurs de SGBD SQL tentent de s'attaquer depuis peut-être des décennies déjà.
La clé est que toutes les vérifications de contraintes doivent être "différées" jusqu'à ce que les deux insertions soient effectuées. Cela peut être réalisé sous différentes formes. Les transactions de base de données peuvent offrir la possibilité de faire quelque chose comme "SET de vérification de contrainte différée ON", et vous avez terminé (si ce n'était du fait que dans cet exemple particulier, vous auriez probablement à vous occuper très fort de votre conception afin pour pouvoir simplement DEFINIR les deux contraintes FK, car l'une d'entre elles N'EST tout simplement PAS une 'vraie' FK au sens SQL !).
Les solutions basées sur des déclencheurs décrites ici produisent essentiellement le même effet, mais elles sont exposées à tous les problèmes de maintenance qui existent avec l'intégrité renforcée par les applications.
Dans leur travail, Chris Date &Hugh Darwen décrivent ce qui est pour moi la vraie solution au problème :l'affectation multiple. C'est essentiellement la possibilité de composer plusieurs instructions de mise à jour distinctes et de faire en sorte que le SGBD agisse dessus comme s'il s'agissait d'une seule instruction. Des implémentations de ce concept existent, mais vous n'en trouverez aucune qui parle SQL.
