Sqlserver
 sql >> Base de Dados >  >> RDS >> Sqlserver

Uma chave estrangeira pode ser NULL e/ou duplicada?


Resposta curta:Sim, pode ser NULL ou duplicado.

Eu quero explicar por que uma chave estrangeira pode precisar ser nula ou pode precisar ser exclusiva ou não exclusiva. Primeiro, lembre-se de que uma chave estrangeira simplesmente requer que o valor desse campo exista primeiro em uma tabela diferente (a tabela pai). Isso é tudo que um FK é por definição. Nulo por definição não é um valor. Nulo significa que ainda não sabemos qual é o valor.

Deixe-me dar um exemplo da vida real. Suponha que você tenha um banco de dados que armazena propostas de vendas. Suponha ainda que cada proposta tenha apenas um vendedor designado e um cliente. Portanto, sua tabela de propostas teria duas chaves estrangeiras, uma com o ID do cliente e outra com o ID do representante de vendas. No entanto, no momento em que o registro é criado, um representante de vendas nem sempre é atribuído (porque ninguém está livre para trabalhar nele ainda), então o ID do cliente é preenchido, mas o ID do representante de vendas pode ser nulo. Em outras palavras, geralmente você precisa da capacidade de ter um FK nulo quando pode não saber seu valor no momento em que os dados são inseridos, mas conhece outros valores na tabela que precisam ser inseridos. Para permitir nulos em um FK, geralmente tudo o que você precisa fazer é permitir nulos no campo que possui o FK. O valor nulo é separado da ideia de ser um FK.

Se é exclusivo ou não exclusivo está relacionado ao fato de a tabela ter um relacionamento um-um ou um-muitos com a tabela pai. Agora, se você tiver um relacionamento um-um, é possível que você tenha todos os dados em uma tabela, mas se a tabela estiver ficando muito grande ou se os dados estiverem em um tópico diferente (o funcionário - exemplo de seguro @tbone deu por exemplo), então você quer tabelas separadas com um FK. Você então desejaria tornar este FK também o PK (o que garante exclusividade) ou colocar uma restrição exclusiva nele.

A maioria dos FKs são para um relacionamento de um para muitos e é isso que você obtém de um FK sem adicionar mais restrições no campo. Então você tem uma tabela de pedidos e a tabela de detalhes do pedido, por exemplo. Se o cliente pedir dez itens de uma vez, ele terá um pedido e dez registros de detalhes do pedido que contêm o mesmo orderID que o FK.