Trigger (ou trigger) é tipo um "callback" no banco de dados, que reage a certos eventos. Em outras palavras, trigger é uma reação automática quando rolam operações como INSERT, UPDATE ou DELETE nas tabelas.
Imagina que você tem um assistente esperto que faz umas paradas pra você. Por exemplo, toda vez que você adiciona um novo registro de estudante, o assistente já atualiza o campo com a data da última alteração. Trigger no banco faz exatamente isso: ela "escuta" os eventos e dispara uma reação programada.
Trigger junta duas coisas:
- Evento: algo acontece na tabela (tipo, inserção de registro).
- Função-trigger: o código que roda quando o evento acontece.
trigger não existe sem estar ligada a uma função. É a função que diz o que fazer quando a trigger dispara.
Exemplos de uso de triggers
Bora ver umas situações onde triggers podem ser bem úteis.
- Atualização automática de dados
Você quer que na tabela onde ficam os registros dos estudantes tenha um campo last_modified que atualiza sozinho toda vez que o registro muda. Ao invés de atualizar esse campo na mão, você pode criar uma trigger que faz isso pra você.
- Logging de alterações
Você quer saber quem e quando mudou os dados na tabela. Trigger pode adicionar automaticamente um registro numa tabela de auditoria (logs) toda vez que os dados mudam.
- Validação de dados
Se na tabela entram dados que precisam seguir umas regras (tipo, idade do estudante tem que ser maior que 18 anos), trigger pode checar os dados antes de inserir.
- Cálculos automáticos
Na tabela orders você guarda os pedidos, e toda vez que entra um pedido novo, precisa atualizar o total de compras do cliente. Ao invés de fazer isso na mão, trigger pode atualizar o total automaticamente.
Quando usar triggers
Agora que já sacamos o que elas fazem, bora falar de quando vale a pena usar triggers de verdade.
Logging e auditoria: triggers são perfeitas pra criar registros de auditoria e rastrear mudanças em tabelas importantes.
Manter integridade dos dados: tipo, se você apaga um curso do banco, trigger pode apagar automaticamente todos os estudantes ligados a esse curso, pra não ficar dado "pendurado".
Automatizar tarefas repetitivas: essas tarefas podem ser atualizar valores calculados, atualizar dados agregados e por aí vai.
Implementar lógica de negócio no banco: ao invés de depender só do código do app, dá pra jogar parte da lógica direto no banco de dados.
Vantagens das triggers
Como você já deve ter percebido, triggers são uma ferramenta poderosa. Olha só o que elas trazem:
Automatização: quase nada de intervenção humana. Por exemplo, rastrear quem muda os dados rola automaticamente.
Menos código duplicado: ao invés de obrigar dev a escrever lógica de atualização ou validação em cada app, dá pra colocar isso no banco.
Garantir integridade dos dados: trigger pode ser uma camada extra de proteção pra garantir que os dados estejam sempre certos.
Desvantagens das triggers
Claro, como qualquer ferramenta, triggers têm seus lados ruins. Bora ver o lado sombrio delas:
Difícil de debugar: triggers rodam "por trás dos panos". Se não funcionam como esperado, debugar pode ser tenso.
Podem afetar performance: se a trigger for muito pesada ou disparar toda hora, pode deixar as queries SQL mais lentas.
Lógica escondida: quando a lógica de negócio tá "enterrada" nas triggers, fica mais difícil pra galera entender o que tá rolando no banco.
Cenários reais de uso
Exemplo 1: Logging de alterações
Imagina que temos uma tabela students com os dados dos estudantes. Queremos rastrear as mudanças nos registros. Pra isso, a trigger vai adicionar um registro na tabela audit_log toda vez que os dados do estudante mudarem.
Exemplo 2: Atualização automática
Na tabela students tem uma coluna last_modified. Queremos que esse valor seja atualizado toda vez que os dados do estudante mudarem. Dá pra fazer isso com uma trigger que dispara depois do update.
GO TO FULL VERSION