PC Toledo

Agora que o Quintas está postando bastante sobre SQL, mostrando os relatos de sua migração de DBF para MySQL, vi que muitos colegas do Fórum se animaram a discutir sobre o tema, independente de ser o MySQL, mas da linguagem em si ( SQL ). Eu utilizo a alguns anos MySQL e nunca utilizei regras no banco ( Stored Procedure / Trigger ), sempre fiz tudo via código, porém, as aplicações que faço são pequenas, não teria como medir se vale a pena ou não o uso, então resolvi abrir esse tópico para discutir sobre o assunto.

Abraços

Eu já pensei nisso também.
Já ouvi dizer de bases que fazem tanto isso, que acaba precisando expandir o servidor pra atender o excesso de coisas que colocam.
Isso precisa ser muito bem pensado.

Alguns dos meus fontes estão ficando com mais comando SQL do que com fonte PRG, seria interessante deixar salvos como stored procedure, e apenas chamar passando os parâmetros "diferentes", como por exemplo intervalo de data.

Uma vantagem de criar stored procedure/trigger seria eliminar cada vez mais fonte PRG, o que deixaria tudo preparado pra usar qualquer coisa depois.

Até rotinas de validar CPF/CNPJ/IE...
Se estiver no banco de dados, se tiver que fazer algo em Windows, Linux, Android, Mobile, etc. já poderiam ser usadas, sem precisar conversão.

Lembrando: as rotinas não precisam mexer com os bancos de dados, podem ser pra isso de validação por exemplo.

Falando somente sobre Trigger, é quase geral essa lista abaixo :

POR QUE NÃO USAR TRIGGER

1 - Ao adotar Trigger resultará na quase impossibilidade de migração de banco de dados. Trigger utiliza linguagerm proprietária.

2 - Trigger é uma linguagem alienígena na aplicação. O sistema possui regras de negócio que disparam ações no banco de dados e você quer mudar o processo pois não se adpata ao sistema. Não é melhor adaptar o seu processo ou solicitar uma mudança pra empresa do software?

3 - Queda de perfmormance. Por mais que você utilize condições para sua Trigger ser rodada ela será chamada para fazer o teste.

4 - Trigger é centralizadora, não fica a cargo do usuário. O usuário não pode decidir se usa ou não. Tá na regra de quem desenvolveu. Se colocar no aplicativo o usuário pode ter domínio sobre o mesmo.

5 - Em um ambiente de segurança, data center por exemplo, dependerá de um DBA responsável para criar, alterar ou apagar a Trigger, visto que esses comandos são DDL.

6 - As atualizações de versões dos sistemas e de banco de dados (incluindo conversões do RM) não olham as Triggers. É um trabalho a mais para administrar e se não testar antes sua produção pode parar.

Fonte : https://www.forumrm.com.br/topic/4561-t ... -n%C3%A3o/

Link prático explicando o que são Trigger e Stored Procedure :

https://pt.stackoverflow.com/questions/ ... procedures

Com SP o negócio está no banco, significa que outras aplicações podem fazer uso das procedures e functions comuns, usamos muito no Oracle.