Opinião: regras de negocio que mudam muito. SQL ou Aplicação?

Oi Denis, seria legal um pouco mais de contexto, que tipo de regras de negocio são essas? A decisão de programar o banco de dados ou a aplicação não pode ser baseado apenas na periodicidade das alterações, na minha opinião.

Essa pergunta é muito interessante.

Vou compartilhar minha opinião. Se os parâmetros de entrada e de saída são sempre os mesmos, creio que vale a pena usar stored procedures.

Apesar de ser perigoso trabalhar um processo onde as regras mudam com muita frequência, o problema seria identificar os valores de entrada e saída. Se eles sempre forem os mesmos, independente da forma como são interpretados/tratados, então a meu ver esta seria uma solução válida.

Uma outra vantagem desta abordagem seria trabalhar num ambiente onde existem várias tecnologias. No meu dia a dia, trabalho num ambiente onde existem sites, aplicações desktop e aplicativos (API) consumindo as mesmas bases de dados. Cada um destes processos foi construído com uma linguagem diferente. Se as regras de negócio ficarem na procedure, se vai gastar menos horas de trabalho com programação.

Eu acredito que as Procedures é a melhor opção nesse caso. Você consegue isolar as regras de negócio em um objeto de banco de dados que tem menos de 1 mega e muito fácil de colocar em produção no BD. No caso da aplicação, será necessário fazer um deploy de arquivo de 60 MB (exemplo), interromper a aplicação para ela subir e o cliente pode ficar desconfiado que o programador fez mais mudanças que o declarado na aplicação. Na procedure o cliente pode comparar a versão em produção e a nova versão e verificar as mudanças. Enfim, nesse caso as procedures tem mais vantagens.