"Ich glaube, das ist unmöglich. Sie können keinen Adressdatensatz erstellen, bis Sie die ID der Person kennen, und Sie können den Personendatensatz nicht einfügen, bis Sie eine AddressId für das PrimaryAddressId-Feld kennen."
Auf den ersten Blick erscheint diese Behauptung SO ansprechend. Allerdings ist es ziemlich propostrous.
Dies ist ein sehr verbreitetes Problem, das die Anbieter von SQL-DBMS schon seit Jahrzehnten zu bekämpfen versuchen.
Der Schlüssel ist, dass alle Constraint-Prüfungen "verzögert" werden müssen, bis beide Einfügungen abgeschlossen sind. Das kann unter verschiedenen Formen erreicht werden. Datenbanktransaktionen bieten möglicherweise die Möglichkeit, so etwas wie "SET deferred Constraint Checking ON" durchzuführen, und Sie sind fertig (wäre es nicht die Tatsache, dass Sie in diesem speziellen Beispiel wahrscheinlich sehr hart mit Ihrem Design herumspielen müssten, um es zu ordnen in der Lage zu sein, die beiden FK-Einschränkungen einfach zu DEFINIEREN, weil eine von ihnen einfach KEINE 'wahre' FK im SQL-Sinne IST!).
Triggerbasierte Lösungen, wie sie hier beschrieben werden, erzielen im Wesentlichen den gleichen Effekt, aber diese sind allen Wartungsproblemen ausgesetzt, die bei anwendungserzwungener Integrität bestehen.
Chris Date &Hugh Darwen beschreiben in ihrer Arbeit, was meiner Meinung nach die wahre Lösung des Problems ist:Mehrfachzuordnung. Das ist im Wesentlichen die Möglichkeit, mehrere unterschiedliche Aktualisierungsanweisungen zusammenzustellen und das DBMS darauf reagieren zu lassen, als wäre dies eine einzige Anweisung. Implementierungen dieses Konzepts existieren, aber Sie werden keine finden, die SQL unterstützt.
