"Acredito que isso seja impossível. Você não pode criar um registro de endereço até saber o ID da pessoa e não pode inserir o registro da pessoa até saber um AddressId para o campo PrimaryAddressId."

À primeira vista, essa afirmação parece TÃO atraente. No entanto, é bastante propostous.

Este é um tipo de problema muito comum que os fornecedores de SQL DBMS vêm tentando atacar há talvez décadas.

A chave é que todas as verificações de restrição devem ser "adiadas" até que ambas as inserções sejam feitas. Isso pode ser alcançado sob diferentes formas. As transações de banco de dados podem oferecer a possibilidade de fazer algo como "SET deferred constraint check ON", e pronto (não fosse pelo fato de que neste exemplo em particular, você provavelmente teria que mexer muito com seu design para para poder apenas DEFINIR as duas restrições FK, porque uma delas simplesmente NÃO É um FK 'verdadeiro' no sentido SQL!).

As soluções baseadas em gatilho, conforme descritas aqui, obtêm essencialmente o mesmo efeito, mas estão expostas a todos os problemas de manutenção que existem com a integridade imposta pelo aplicativo.

Em seu trabalho, Chris Date e Hugh Darwen descrevem o que é a verdadeira solução para o problema:atribuição múltipla. Ou seja, essencialmente, a possibilidade de compor várias instruções de atualização distintas e fazer com que o SGBD atue sobre elas como se fosse uma única instrução. Existem implementações desse conceito, mas você não encontrará nenhuma que fale SQL.