Não usar restrições de chave estrangeira na prática real. Está tudo bem? [duplicado]

Nada é gratuito. Às vezes, não ter algo também não é de graça. Tanto ter como não ter declarado chaves estrangeiras traz custos e benefícios.

O objetivo de uma chave estrangeira (FK) é garantir que esta coluna aqui só possa ter valores que venham daquela coluna ali ¹ . Dessa forma, podemos ter certeza de que apenas capturamos pedidos para clientes que realmente existem, para produtos que realmente produzimos e vendemos. Muita gente acha que isso é uma boa ideia.

A razão pela qual os declaramos dentro do DBMS é para que ele possa cuidar de aplicá-los. Nunca permitirá a entrada de quaisquer dados que infrinjam as regras. Além disso, nunca permitirá que você se livre dos dados necessários para fazer cumprir as regras. Ao delegar essa tarefa à máquina, podemos ter confiança na integridade dos dados, não importa qual seja sua origem, quando foi escrito ou por qual aplicativo veio. Claro que isso tem um custo. O SGBD tem que verificar se as regras estão sendo seguidas, para cada linha, para cada consulta, o tempo todo. Isso leva tempo e esforço, que é uma carga no servidor. Também exige que os humanos enviem DML em uma sequência que respeite as regras. Chega de forçar um pedido astutamente e depois conversar com o administrador. Oh não humano impertinente, você deve primeiro criar o Cliente,

Sem chaves estrangeiras, somos muito mais livres com o que podemos fazer e com a ordem em que podemos fazê-lo. As linhas problemáticas podem ser removidas ad hoc para permitir a conclusão de processos críticos. Os dados podem ser corrigidos depois, quando o pânico acabar. Os INSERTs geralmente são um pouco mais rápidos (o que aumenta com o tempo) porque nenhuma verificação de FKs é feita. Subconjuntos arbitrários de dados podem ser extraídos do banco de dados conforme desejado sem ter que garantir que todos os dados de suporte sejam incluídos. E assim por diante. Isso pode ser absolutamente bom se as pessoas envolvidas conhecerem o sistema, tomarem notas cuidadosas, tiverem boas rotinas de reconciliação, entenderem as consequências e tiverem tempo para se arrumarem. O custo é que algo, em algum lugar, é perdido uma vez e o banco de dados se deteriora em um lixo pouco digno de crédito.

Algumas equipes colocam as verificações no aplicativo e não no banco de dados. Novamente, isso pode funcionar. Parece-me, no entanto, que a carga total do servidor será praticamente a mesma (ou um pouco maior) com essa abordagem, mas o risco de esquecer algum check-in de um pouco de código em algum lugar é muito maior. Com DRI, a regra é comunicada ao computador uma vez e é aplicada para sempre. No código do aplicativo, ele deve ser reescrito a cada novo programa.

Pelos meus dois centavos, sou a favor de chaves estrangeiras. Deixe os computadores fazerem o que são bons em fazer, como a verificação repetitiva de rotina de que os valores das colunas correspondem. Nós, humanos, podemos nos concentrar em sonhar com coisas novas e interessantes. Tendo assumido a responsabilidade por um sistema há alguns meses, estou adicionando FKs à maioria das tabelas. Há alguns, no entanto, onde eu não vou adicioná-los. É aqui que coletamos dados de fontes externas. O custo de rejeitar essas linhas é maior do que o custo de aceitar dados incorretos e corrigi-los posteriormente. Portanto, para essas poucas tabelas, não haverá chaves estrangeiras. Faço isso de olhos abertos, sabendo que temos monitoramento e procedimentos corretivos.

¹ Reconheço a existência de restrições de chave estrangeira de várias colunas.

Seu superior está repugnantemente errado. As restrições FK são uma linha de código para garantir a integridade dos dados. O que leva mais tempo,

• literalmente uma linha de código em uma linguagem declarativa e, às vezes, menos, pois você pode adicionar chaves estrangeiras inline ao usar CREATEa tabela.
• ou, para assumir a integridade e lidar com as desvantagens de suposições fracassadas.

Não há razão para não usar restrições de chave estrangeira e usar um banco de dados relacional. Você tem dois trabalhos como SQL DBA:

• Faça o esquema com DDL.
• Esquema de acesso com DML.

Se você não está garantindo a integridade de seus dados com o esquema, está simplesmente pulando parte do trabalho. A própria natureza de uma transação é garantir atomicamente tudo ou nada. Você deseja definir "todos" sem usar restrições de chave estrangeira? Isso é uma pita.

CREATE TABLE foo ( int a PRIMARY KEY );
CREATE TABLE bar ( int b REFERENCES foo );
CREATE TABLE baz ( int b );

Agora faça uma transação atômica para barebaz

1. insere no foo.avalor (1). Falha se o valor existir.
2. insere em outra tabela ( bar.bou baz.b) o mesmo valor, 1 e falha se o valor não existir em foo.a.

Qual deles economiza tempo?

É quase sempre melhor declarar restrições de chave estrangeira do que usar chaves estrangeiras sem restrição no DBMS. A restrição de chave estrangeira mantém a integridade referencial, o que evita uma forma de corrupção de dados.

A alternativa de impor a integridade referencial no nível do aplicativo quase sempre custa tanto ou mais em recursos do computador e esforço do programador quanto a restrição do DBMS custaria.

A alternativa de não manter a integridade referencial geralmente leva a dados corrompidos e resultados não confiáveis.

As chances são muito grandes de que a política do seu site tenha sido equivocada desde o início. Existem exceções para isso, mas são poucas e distantes entre si.

Isso é algo que realmente precisaria ser testado para sua própria situação, mas para fornecer a integridade dos dados de chaves estrangeiras ao excluir ou atualizar rapidamente os dados, você pode analisar em cascata.

CREATE TABLE ChildTable (
    id INT NOT NULL IDENTITY(1,1), 
    parent_id INT,
    FOREIGN KEY (parent_id)
        REFERENCES parent(id)
        ON DELETE CASCADE
);