"Creo que esto es imposible. No puede crear un registro de dirección hasta que conozca el ID de la persona y no puede insertar el registro de persona hasta que conozca un ID de dirección para el campo ID de dirección principal".
A primera vista, esa afirmación parece MUY atractiva. Sin embargo, es bastante propicio.
Este es un tipo de problema muy común que los proveedores de SQL DBMS han estado tratando de atacar durante quizás décadas.
La clave es que todas las comprobaciones de restricciones deben "diferirse" hasta que se hayan realizado ambas inserciones. Eso se puede lograr bajo diferentes formas. Las transacciones de la base de datos pueden ofrecer la posibilidad de hacer algo como "CONFIGURAR la verificación de restricciones diferidas", y ya está (si no fuera por el hecho de que en este ejemplo en particular, probablemente tendría que meterse mucho con su diseño para poder para poder simplemente DEFINIR las dos restricciones FK, ¡porque una de ellas simplemente NO ES un FK 'verdadero' en el sentido de SQL!).
Las soluciones basadas en activadores, como se describe aquí, logran esencialmente el mismo efecto, pero están expuestas a todos los problemas de mantenimiento que existen con la integridad impuesta por la aplicación.
En su trabajo, Chris Date y Hugh Darwen describen cuál es la verdadera solución al problema:la asignación múltiple. Es decir, esencialmente, la posibilidad de componer varias declaraciones de actualización distintas y hacer que el DBMS actúe sobre ellas como si fuera una sola declaración. Existen implementaciones de ese concepto, pero no encontrará ninguna que hable SQL.
