A coluna (ou colunas) de uma chave primária deve ser NOT NULL. Um registro não pode ser identificado exclusivamente por um NULL. Portanto, as colunas de ID na extremidade referenciada da chave estrangeira devem ser definidas como NOT NULL.

No entanto, é uma decisão de design legítima que um relacionamento de chave estrangeira seja opcional, e a maneira de representar isso é tornando o final de referência da chave opcional, ou seja, permitindo NULLs.

Em termos de modelagem de dados, o que você descreveu é um arco (exclusivo):"uma tabela ... com duas ou mais chaves estrangeiras onde uma e apenas uma delas pode ser não nula". Na modelagem lógica, os arcos são perfeitamente aceitáveis, mas há uma forte opinião a favor de implementá-los como tabelas separadas. No seu cenário, isso seria uma Sale genérica tabela mais duas tabelas de subtipo, VehicleSale e PieceSale .

As vantagens da implementação de tabela separada são:

• mais fácil de aplicar as restrições de chave estrangeira;
• mais fácil adicionar colunas adicionais relacionadas a (digamos) vendas de veículos que não se aplicam a vendas de peças;
• mais fácil de estender o modelo com subtipos adicionais;
• modelo de dados mais claro, que pode simplificar o desenvolvimento de aplicativos.

No entanto, as vantagens não são todas unidirecionais. Embora seja muito fácil garantir que uma Sale se aplica a uma VehicleSale ou uma PieceSale mas não ambos, aplicando uma regra de que uma Sale deve ter um registro de criança realmente fica bem complicado.

Portanto, o conselho predominante é que um arco exclusivo está errado e geralmente é um bom conselho. Mas não é tão claro como alguns dizem.