Na minha estrutura de banco de dados no SQL Server, tenho 3 tipos de produtos que requerem informações diferentes sobre o pedido. Então, eu criei uma Customersmesa e três tabelas diferentes ordens: OrdersForProductAs, OrdersForProductBs, OrdersForProductCs. Todas as tabelas de pedidos têm um para muitos relacionamentos na Customerstabela.
Também tenho outra tabela que Paymentscontém e mantém os detalhes do pagamento. Mas tenho dúvidas aqui sobre como estruturá-lo.
Como tenho vários tipos de produtos e um cliente pode ter pedidos de vários produtos ao mesmo tempo, preciso relacionar essas três tabelas de pedidos à Paymentstabela.
A outra questão é que um cliente pode ter um pedido para apenas um tipo de produto. Portanto, as colunas FK na Paymentstabela precisam ser nullable.
Minha pergunta é se essas nullablecolunas FK seriam uma dor de cabeça para mim a longo prazo ou não? De um modo geral, seria uma má prática ter colunas FK anuláveis em uma tabela?
Respostas:
Gostaria de perguntar por que você tem
OrdersForProductXtabelas.É possível que o problema do FK que você perguntou possa ser planejado ...
Se essas tabelas tiverem a mesma estrutura, você simplesmente precisará de uma
ProductTypecoluna em algumaOrderProducttabela. Em seguida,Paymentbasta vincular a isso com um FKSe a tabela tiver estruturas diferentes, presumo que elas tenham alguns atributos em comum. Portanto, você pode ter uma
OrderProducttabela comum e, em seguida, tabela filha específica por tipo de produto (veja abaixo). Novamente,Paymentbasta vincular à tabela comum com um FKEste é o "padrão de superchave / subtipo"
(OrderID, ProductType)OrderProduct
OrderProductA
OrderProductB
fonte
NULLcolunas FK com essa abordagem.Evite "chaves estrangeiras" anuláveis. Eles têm várias desvantagens.
A restrição em uma linha de referência nem sempre é imposta quando a chave estrangeira contém um nulo. No entanto, esse comportamento padrão não é consistente entre diferentes DBMSs. Alguns DBMSs suportam opções de configuração para alterar o comportamento de chaves estrangeiras anuláveis e outras não. Os desenvolvedores e usuários de SQL podem, portanto, não ter certeza sobre o que uma restrição de chave estrangeira anulável realmente significa da perspectiva da integridade dos dados. Portar o banco de dados entre produtos DBMS ou mesmo entre servidores diferentes usando o mesmo produto pode gerar resultados inconsistentes.
As ferramentas de design de banco de dados, as ferramentas de integração e outros softwares nem sempre os suportam corretamente e os resultados que eles produzem podem estar errados.
Chaves estrangeiras são freqüentemente usadas em junções e outras lógicas de consulta, compondo os problemas para usuários que pensam que a restrição está em vigor quando não existe ou que não conhecem a lógica que está sendo aplicada pelo seu DBMS específico.
Alguns recursos de otimização de consulta que permitem reescritas e outras otimizações podem não estar disponíveis quando uma chave estrangeira é anulável.
Em termos lógicos, uma restrição de "chave estrangeira" anulável não faz muito sentido lógico. De acordo com o padrão SQL, essa restrição não pode ser violada, mesmo que a tabela que está sendo referenciada esteja vazia. Isso contradiz uma das justificativas alegadas mais comuns para o uso de um nulo - que representa o caso "desconhecido". Se não houver valores válidos para X, qualquer X "desconhecido" certamente não poderá ser um valor válido - e, no entanto, o SQL permitirá.
Chaves estrangeiras anuláveis são completamente desnecessárias. Você sempre pode decompor a chave estrangeira em uma nova tabela ou usar um padrão de supertipo / subtipo para que nulos não sejam necessários. Por uma questão de simplicidade e precisão, é melhor deixar nulos do que colocá-los.
fonte
Nunca ouvi dizer que era uma prática ruim usar colunas FK anuláveis. Eles são o ajuste ideal para uma coluna que faz referência a outra tabela, mas pode não ser preenchida (ou seja, são dados opcionais).
(Por que você acha que seria um problema?)
fonte