O que são Triggers?
Triggers são pequenas rotinas programadas no banco de dados, semelhantes às conhecidas Stored Procedures. Porém, como o nome indica (trigger = gatilho), uma Trigger pode ser disparada em resposta a um determinado evento. Geralmente esse evento é uma alteração na tabela, causada pelos comandos insert, delete ou update.
Trigger é uma ação programa, que pode ser disparada em resposta a um evento, como um comando INSERT, DELETE ou UPDATE.
Podemos, por exemplo, programar uma Trigger para gravar na tabela A, informações de auditoria sobre alterações nos registros na tabela B.
As Triggers também são úteis para aumentar a segurança e evitar inconsistências. Você pode, por exemplo, bloquear alterações em massa e comandos DELETE através de Triggers.
Alguns SGBDs oferecem recursos adicionais. Por exemplo, no SQL Server é possível criar Triggers para views e no Oracle para alterações de schema, como drop.
Por que usar Triggers?
No geral, Triggers podem ser escritas para diferentes propósitos. A fim de ilustrar um desses cenários, considerando que desejamos auditar as alterações realizadas em tabela, como evitar que fique sob a responsabilidade do desenvolvedor lembrar de chamar as rotinas de log? A resposta pode estar na criação de uma Trigger, disparada em resposta ao comando update.
Outro uso comum para as Triggers é garantir que as alterações ocorram de forma mais segura. Uma vez que em uma Trigger temos acesso aos comandos do SGBD, podemos anular a alteração após concluir que seu impacto nos dados será negativo. Um exemplo disso é dar ROLLBACK TRANSACTION em um update caso seja identificado que o mesmo afetará mais de um registro.
Quando não usar Triggers?
Como já dizia o Tio Ben: com grandes poderes vêm grandes responsabilidades. No geral, as Triggers podem ser utilizadas para ações que devem ser transparentes ao programador. Um exemplo disso é a criação de registros de log, duplicação de dados entre tabelas, auditoria, etc.
Porém, adicionar às Triggers qualquer regra de negócio pode retirar a clareza da aplicação e gerar dúvidas quanto ao seu funcionamento. Considere um sistema de vendas. Pode ser tentador criar uma Triggers para que após a emissão do cupom fiscal seja realizada a baixa do estoque automaticamente. Mas será que o banco de dados é o melhor local para declararmos essa lógica? Ao remover ou fragmentar o domínio da aplicação podemos tornar a sua leitura confusa e manutenção suscetível a erros difíceis de rastrear.
Um outro detalhe importante é que Triggers podem ser disparadas em cadeia. Portanto, mantenha sob controle quais tabelas possuem Triggers e como essas Triggers afetam outras tabelas no banco de dados. Caso você tenha duas tabelas para as quais foram registradas Triggers ON UPDATE, caso uma tabela atualize a outra através da Trigger você estará em um problema conhecido como Trigger Storm, pois ambas as tabelas se atualizarão indefinidamente.
Um ótimo final de semana para todos :)
