Isso faria algum sentido em fazer com que o aplicativo reforçasse a integridade do banco de dados em vez de ter chaves estrangeiras, verificar restrições etc.?
Quanto de melhoria de desempenho se pode esperar por não impor a integridade do banco de dados por meio de ferramentas internas de banco de dados?
Respostas:
Verdade seja dita, não apenas você não verá muita perda de desempenho por ter restrições de chave estrangeira no banco de dados, mas também verá aprimoramentos de desempenho. O otimizador de consultas do SQL Server foi criado com base no conceito de chaves primárias e externas, além de outros tipos de restrições de dados. Se estes estiverem implementados e aplicados, o otimizador poderá tirar proveito deles para obter um melhor desempenho. Aqui está uma postagem de blog com um exemplo simples que mostra isso em ação.
Se você estiver em um caso extremo em que realmente possui mais inserções do que leituras (e atualizações e exclusões exigem leituras, então elas geralmente acabam adicionando à contagem de leituras), talvez faça sentido remover restrições dos dados para desempenho, talvez . Mas como a grande maioria dos bancos de dados é orientada para leitura, você está sacrificando o desempenho, sem aprimorá-lo.
E nada disso menciona o fato de que a integridade dos dados é melhor gerenciada no banco de dados, já que você só precisa criá-los uma vez, onde, como se você fizesse todo o trabalho em código, talvez seja necessário várias vezes para vários aplicativos (a menos que você projete sua camada de acesso a dados com cuidado e exige que todos os aplicativos acessem o banco de dados para passar pela mesma camada).
Se você estiver usando um sistema de banco de dados relacional, eu digo, por que não usá-lo realmente? Se você não precisar de dados relacionais, vá com o Hadoop ou outra coisa.
Muitos desenvolvedores de aplicativos pensam assim.
Quando você estiver tentado a delegar a integridade dos dados no código do aplicativo, pense em "Todo programador e todo aplicativo que acessa esse banco de dados a partir de agora até o final dos tempos precisa acertar perfeitamente, todas as vezes".
Quais são as hipóteses?
Mesmo se houver algum ganho de desempenho, é insignificante comparado ao retorno da integridade referencial e da integridade generalizada dos dados.
Longe vão os dias em que um banco de dados é um armazenamento de dados estúpido. Aproveite o poder que a RDBMS oferece.
Os ganhos de desempenho não são tudo, especialmente em uma escala tão pequena como essa. Mas quando você descobrir que tem um suposto relacionamento de chave estrangeira que seu aplicativo deve impor, e acontece que não é uma chave primária na tabela de referência, você se preocupará muito pouco com o ganho de desempenho (se houver, posso não fale sobre os detalhes disso).
É prática comum eliminar restrições (chaves estrangeiras, CHECK, etc) e índices, se você estiver fazendo uma carga de dados grande o suficiente, e reativar / implementar as restrições e índices posteriormente. Essa validação tem um custo de tempo. Isso pressupõe que você não possa usar a sintaxe de carregamento em massa específica do banco de dados (incluindo a minimização do registro).
É impossível dizer quanto de um aumento de desempenho é esperado - cada situação é única (tipos de dados, design etc.). A única maneira de realmente saber é testar.
Existem algumas vezes em que as restrições atrapalham:
Quando você precisar usar a herança de tabela única (STI). Imagine que você vende para indivíduos e organizações. Você precisará de uma única tabela "Parte" cuja linha seja um indivíduo ou uma organização. STI significa que você precisa de alguns campos anuláveis que não devem ser nulos. A herança de tabela de classe resolve isso, mas isso é mais difícil para alguns ORMs. O ActiveRecord do Ruby suporta apenas STI, por exemplo.
Quando você precisa oferecer suporte a versões de rascunho de uma entidade, isso pode não ser completamente válido. Você pode armazenar um rascunho como json, mas é mais difícil reutilizar o mesmo identificador no cliente - imagine que ele foi salvo com id = 5, editado para não ser válido e salvo automaticamente como draftid = 99. Nesse caso, todos os seus campos provavelmente teriam que ser anuláveis.