Banco de Dados - Triggers

Alterações em cascata, limpeza de registros etc.

Trigger é um bom aliado desde que saibas trabalhar com ele. Se não souber, fica danoso.

Até!

Triggers são muito usadas na arquitetura cliente-servidor, onde grande parte da lógica de negócio está no banco. Desde que comecei a usar o Hibernate, nunca mais escrvi triggers…
Mas elas são úteis para garantir que alterações acidentais no banco sejam efetuadas.

Só toma cuidado para não sair criando trigger pra tudo e comprometer a performance.

Se vc não tiver a necessidade que sua aplicação funcione com vários banco de dados, eu recomendo não só o uso de triggers mas de outros objetos do banco como procedures, functions, packages, etc. O fato de escrever a regra de negócios no banco facilita em muito quando temos uma mesma base acessada por várias aplicações. É uma maneira de garantir que algo vai ser feito de uma só maneira em um só ponto. Também aumenta demais a performance pois o processamento é feito no servidor, sem pesar a rede. Isto ocorre mesmo em aplicações que não sejam cliente-servidor.

Imagine uma situação: um processo que é rodado em uma aplicação Web Java e em algum desktop feito em Delphi. Você teria que escrever a mesma coisa 2 vezes e toda vez que quiser fazer uma manutenção terá que mexer em 2 lugares.

Agora, se você SÓ utiliza Java e compartilha bem suas bibliotecas de acesso ao banco, manter o código na aplicação pode ser uma boa saída. O único problema é que se surgir uma nova tecnologia você terá que reescrever seu código, coisa que você não teria que fazer se tivesse sua regra de negócios no banco. Mas aí surge um outro problema que é a dependência de um SGDB.

Resumindo: coloque na balança e tente visualizar futuras alterações e integrações do projeto.

Um outro fator importante: regra de negócios no banco não é ficar enchendo o banco de tranqueiras e achar que está usufruindo o “máximo” de recursos do banco. Qualquer banco de dados merece uma sessão de estudo, coisa que não vejo os programadores fazerem por aí.

Usei muito para integridade do banco de dados. Pra evitar algumas exclusões indesejadas, mas somente quando estas envolviam algumas regras de negócio.

Agora uma dica de experiência própria: lembre-se de documentar bem detalhado o uso dessas triggers. Já trabalhei em um projeto onde continuei o desenvolvimento de outra pessoa. Esse outro “ser” não tinha documentado o uso de algumas triggers. Resultado: perdi um tempão de desenvolvimento para resolver uns problemas que bastava somente “desligar” essas triggers no banco.

[]'s.