Lógica de negócios: banco de dados versus código [duplicado]

Consulte Quanta lógica de negócios o banco de dados deve implementar? para discussão anterior.

Em geral, todos querem que as coisas sejam feitas na camada que controlam. Porque então eles controlam isso.

Todo fornecedor de banco de dados quer que as pessoas coloquem tanta lógica no banco de dados quanto possível. Porque isso trava você no banco de dados. O raciocínio é que, se vários aplicativos usarem o mesmo banco de dados, eles reutilizarão o código.

No entanto, os programadores discordam enfaticamente. Bancos de dados oferecem opções de programação ruins. Implantar código em bancos de dados é difícil. Os bancos de dados não possuem ferramentas básicas para controle de revisão, edição interativa, implantação e testes unitários. Procedimentos armazenados tendem a envolver horríveis para depurar a ação à distância. Tornou-se menos comum ter vários aplicativos atingindo o mesmo banco de dados. E se você tiver que fazer algo em escala, o único gargalo que é mais difícil de consertar é o seu banco de dados.

Meu viés é claro. Eu sou um programador.

Mas eu tenho programado por quase 20 anos, principalmente como um programador de back-end que é responsável por dados. Eu vi o argumento muitas vezes para mover a lógica para o banco de dados. Eu vi sistemas que o fizeram e sistemas que o evitaram. Eu tive que migrar bancos de dados, migrar bases de código, etc, etc, etc.

As piores bagunças sempre ocorreram quando a lógica de negócios estava no banco de dados. Eles sempre foram os mais difíceis de consertar. E posso dizer que, embora muitas vezes tenha encontrado a alegação de que "nós movemos a lógica para o banco de dados para desempenho", o desempenho é quase sempre melhor com um modelo de dados limpo normalizado, bons índices, uma camada de cache na frente do banco de dados. e algoritmos sãos implementados em uma linguagem de programação moderna.

Estou firmemente convencido de que sempre que possível , a lógica de negócios deve ser mantida na camada de software e não na camada de banco de dados. Note que sempre que possível fica muito aquém de sempre .

Existem strongs argumentos para ambos os lados e, como sempre, use bom senso de engenharia para decidir, para cada projeto, quanto peso deve ser aplicado a cada ponto antes de decidir qual é a escolha mais apropriada.

( como outras pessoas fazem sugestões nos comentários, elas podem ser adicionadas à lista )

Argumentos para o banco de dados que lida com a lógica de negócios:

• A lógica de negócios precisa de dados para operar. Obtendo o processamento lógico o mais próximo possível dos dados oferece melhor desempenho
• Um lugar para aplicar atualizações

Argumentos para as camadas de software que lidam com a lógica comercial:

• O software bem escrito é normalmente muito mais fácil de entender, depurar e manter do que procedimentos armazenados SQL.
• Os Servidores de Aplicativos podem ser expandidos e ampliados se o aplicativo da Internet se tornar popular.

Como desenvolvedor profissional experiente, precisando de uma solução rápida para melhorar a latência do aplicativo, a opção pode ser mover alguma lógica de negócios de execução lenta para um procedimento armazenado no banco de dados e / ou para implementar o cache de processos lentos.

Há, no entanto, uma pegadinha séria com lógica de negócios baseada em banco de dados. Se o seu aplicativo precisar ser ampliado, sempre prefira sistemas / processos que possam ser expandidos (com isso, você pode adicionar mais servidores ao pool de processamento). Bancos de dados SQL só podem escalar (você precisa encontrar um servidor mais poderoso para substituir o existente.) Se seu aplicativo tiver muita lógica de negócios de banco de dados, você encontrará esse problema anteriormente.

Dois pontos muito importantes estão faltando em seus argumentos pró-banco de dados:

• performance : o código do banco de dados é executado com acesso direto aos dados, evitando transferências desnecessárias (seja buscando APIs e esquemas de mapeamento na mesma máquina ou na rede para comunicação cliente / servidor)
• consistência : como vários aplicativos podem acessar / atualizar o mesmo banco de dados, encapsulando a consistência e as regras de negócios centralmente, garante que eles sejam aplicados de maneira confiável.

Mas alguns pontos muito importantes também estão faltando em seus argumentos contra-banco de dados:

• escalabilidade : quanto mais você colocar no banco de dados, mais esse componente se tornará um gargalo. É claro que você pode ter servidores maiores e adicionar CPUs, mas, mais cedo ou mais tarde, você atingirá os limites físicos.

• bloqueio de fornecedor : o SQL é muito padronizado, mas os idiomas para gatilhos e procedimentos são bastante diversificados e geralmente proprietários: T-SQL para a Microsoft, PL / SQL para Oracle, qualquer idioma para o DB2. O desenvolvimento no banco de dados o trava para um fornecedor e não permite que você aproveite o aumento da concorrência ou migre para novos ambientes operacionais.

• arquitetura legada : supercentralização de dados e processamento em grandes servidores ... Isso não nos traz de volta à era dos mainframes? Isso parece obsoleto hoje em dia, quando novas tendências arquitetônicas emergem, visando à máxima escalabilidade: NoSQL bancos de dados de diferentes tipos ideais para desenvolvimento orientado a objetos , microsserviços , com cada microsserviço tendo seu próprio banco de dados e arquitetura bigdata, como arquiteturas lambda onde todos os pipelines de processamento estão fora do banco de dados.

• argumentos obsoletos : o tempo de código cobol redundante propenso a erros copiado entre aplicativos é longo. O que só poderia ser confiavelmente encapsulado em um RDBMS ontem, pode muito bem ser encapsulado em arquiteturas de software modernas, usando componentes orientáveis a objeto, bibliotecas e sistemas de controle de versão que podem ser mantidos e reutilizados.

Para resumir:

• sim, existem argumentos válidos para colocar o máximo de lógica no lado do banco de dados. Mas esses argumentos, no entanto, já não atendem a novas necessidades e restrições da escala da Internet, da mudança tecnológica e do surgimento de bigdata.
• não, não acho que exista uma abordagem universal melhor. A abordagem mais adequada deve ser escolhida por um arquiteto de software, caso a caso, com base nos requisitos e necessidades concretos.

Além de todos os fatos que já foram apontados, lembre-se também de ter lógica de negócios em seu código, em vez de o banco de dados acabar sendo mais barato.

Ao procurar um desenvolvedor para um aplicativo escrito em PHP e usando MySQL como um banco de dados, se sua lógica de negócios for armazenada no banco de dados, um simples programador PHP não é suficiente, e você terá que encontrar alguém que também saiba escrever , depurar e otimizar procedimentos armazenados. De repente você precisa de um cara que saiba não apenas uma coisa, PHP, mas duas, PHP e MySQL.

E nem pense em mudar para um mecanismo de alto desempenho como PostgreSQL , você também precisa contratar um cara para transformar todos os procedimentos armazenados em PL / SQL .

Quando se tem lógica de negócio no código, isso é apenas uma questão de escrever uma nova camada de abstração para o PostgreSQL e trocar as dependências em seu aplicativo, boom, seu aplicativo de repente conhece o PostgreSQL.

As respostas anteriores dão grandes razões para por que é mais fácil / melhor colocar a lógica no código do aplicativo em um banco de dados. Uma exceção que gostaria de destacar é ao usar uma pilha de banco de dados / tecnologia de big data. Nesse caso, muitas das desvantagens desaparecem:

• Você pode escrever testes de unidade, já que o código real que você escreveu está no banco de dados.
• Você pode depurar, embora através de testes de unidade.
• Você tem controle de versão, já que é o código.

E as vantagens de ter lógica no banco de dados tornam-se muito mais importantes:

• Dependendo da quantidade de dados que estão sendo processados, pode ser irracional enviar os dados para o código do seu aplicativo.
• Escalonamento - seu código é dimensionado da mesma forma que o banco de dados é dimensionado - em muitos casos, o desempenho e o armazenamento são lineares no número de nós (máquinas).

Grande pergunta - isso é algo que defendo no escritório com muita regularidade.

Minha opinião é que a maior parte da lógica deve estar no código. É sempre muito tentador usar uma variedade de idiomas porque cada um deles tem seus pontos strongs, mas, a menos que você tenha uma configuração de desenvolvimento perfeita (o que é muito raro), é preferível manter um idioma.

As pessoas mencionaram o teste de unidade / revisão de controle de revisão, mas uma coisa muito importante é a implantação. Ter que sincronizar alterações no código do banco de dados com alterações no código pode ser perigoso.

Se você está em uma empresa de desenvolvimento de software em grande escala, você pode ter pessoas especializadas o suficiente para conhecer ambos os lados (programação de banco de dados versus codificação), mas é difícil encontrar pessoas que possam fazer malabarismos entre os dois mundos. importante, quem faz as escolhas certas quando se trata de decidir qual parte da lógica precisa ser em qual idioma).

Pessoalmente, acho linguagens de programação SQL muito primitivas, e ferramentas de desenvolvimento para elas ainda piores. Então, eu preferiria linguagens de programação modernas. Um bom ORM pode salvar a maioria dos desenvolvedores de saber qualquer coisa sobre o banco de dados, e vale a pena investir em. As pessoas mencionaram a eficiência de fazer as coisas do lado do servidor, e isso não deve ser abandonado. Existem alguns padrões de programação muito bons que permitem expressar operações do lado do servidor usando o que parece ser uma API do lado do cliente (por exemplo, IQueryable em C #).

Na prática, ainda estou usando as visualizações ímpares ou procedimentos armazenados, mas eles são geralmente puramente para agregação e não têm lógica de 'negócios' neles. Isso é bastante útil, pois eles podem ser usados como fontes para pivotables do Excel, por exemplo.