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.