Ouvindo Opiniões

Eu sou favorável às regras de negocio na aplicação. Na minha opinião programar no banco de dados não é a melhor das opções, o banco deveria ser apenas um meio de armazenagem, não um complemento à linguagem de programação, ainda que seja para guardar as regras de negócios.

Montar Stored Procedures, Triggers e outros babados no banco, ao invés de fazê-los na aplicação costuma ser uma faca de dois gumes, pois quando o camarada coloca triggers no banco que foram propostas para serem executadas quando seu programa fizer alguma coisa. Porém, o programador muitas vezes esquece que de vez em quando alguém irá rodar uma ferramenta de execução de sentenças no banco para alguma atividade ou mesmo corrigir um registro na mão ou então outro programa poderá lançar mão da tabela lá para interfacear com alguma outra aplicação. Sendo assim, a trigger que você criou pra atender a um propósito em um determinado sistema, irá ser executada DO MESMO JEITO. E, se a ação desta trigger estiver atrelada a atividades que seu sistema teria que executá-las antes da execução da referida trigger, elas (as atividades) não serão executadas neste caso. Ou seja, o resultado disto é totalmente imprevisível.

Triggers devem ser usadas com um extremo critério para que elas não se transformem de anjos em demônios.

Stored Procedures devem ser usadas apenas para execução de alguma rotina automatizada no banco através de uma ferramenta de Query do próprio banco. Algumas até podem ser executadas de dentro do sistema que não haverá problemas, mas não vamos nos esquecer que SPs impactam diretamente no desempenho do banco. Ou seja, é tirar o comprometimento de performance da sua aplicação para transferi-la para o banco que, em muitos casos, se torna inconveniente dado o dimensionamento e a performance do link da rede.