SQL Triggers e quando ou quando não usá-los.

42

Quando eu estava aprendendo sobre SQL, sempre me disseram, use somente gatilhos se você realmente precisar e opte por usar procedimentos armazenados, se possível.

Agora, infelizmente, na época (alguns anos atrás), eu não estava tão curioso e preocupado com os fundamentos como estou agora, então nunca perguntei o motivo.

Qual é a opinião da comunidade nisso? É apenas a preferência pessoal de alguém, ou os gatilhos devem ser evitados (assim como os cursores), a menos que haja uma boa razão para eles.

    
por John Mitchell 03.12.2011 / 07:23
fonte

7 respostas

30

O artigo da Wikipédia sobre os gatilhos do banco de dados apresenta uma boa visão geral do que são os gatilhos e quando usá-los em diferentes bancos de dados.

A discussão a seguir é baseada apenas no SQL Server.

O uso de gatilhos é bastante válido quando seu uso é justificado. Por exemplo, eles têm um bom valor em auditoria (mantendo o histórico de dados) sem exigir código de procedimento explícito com todos os comandos CRUD em todas as tabelas.

Os acionadores fornecem controle antes que os dados sejam alterados e logo após a alteração dos dados. Isso permite:

  • Auditar como mencionado antes
  • Validação e verificação de segurança do negócio, se assim for desejado. Por causa desse tipo de controle, você pode executar tarefas como a formatação de colunas antes e depois de inserções no banco de dados.

I was always told, only use triggers if you really need to and opt to use stored procedures instead if possible.

Podem ser algumas das razões para isso:

  1. Algumas funções que os acionadores costumavam fazer nos velhos tempos agora podiam ser executadas de outras maneiras, como atualização de totais e cálculo automático em uma coluna.
  2. Você não vê onde o gatilho é invocado examinando o código sozinho sem saber que eles existem. Você vê o efeito deles quando vê os dados sendo alterados e às vezes é intrigante descobrir por que a mudança ocorreu, a menos que você saiba que há um gatilho ou mais atuando na (s) tabela (s).
  3. Se você usar vários controles de banco de dados, como CHECK, RI, Triggers em várias tabelas, o fluxo detalhado da transação se tornará complexo para entender e manter. Você precisará saber exatamente o que acontece quando. Mais uma vez, você precisará de uma boa documentação para isso.

Algumas diferenças entre gatilhos e procedimentos armazenados sem gatilho são (entre outros):

  • Um procedimento armazenado sem acionamento é como um programa que precisa ser chamado explicitamente a partir do código ou de um planejador ou de um trabalho em lote, etc. para fazer seu trabalho, enquanto um disparador é um tipo especial de procedimento armazenado dispara como uma resposta de um evento em vez de ser executado diretamente pelo usuário. O evento pode ser uma mudança de dados em uma coluna de dados, por exemplo.
  • Os gatilhos têm tipos. Disparadores DDL e Disparadores DML (dos tipos: INSTEAD OF, For e AFTER)
  • Procedimentos armazenados sem acionamento podem fazer referência a qualquer tipo de objeto, no entanto, para fazer referência a uma exibição, você deve usar acionadores INSTEAD OF.
  • No SQLServer, você pode ter qualquer número em procedimentos armazenados sem disparar, mas apenas 1 gatilho INSTEAD OF por tabela.
por 03.12.2011 / 10:22
fonte
8

Os acionadores são um requisito para qualquer regra complexa de integridade de dados. Eles não podem ser aplicados em nenhum lugar, exceto no banco de dados, ou você terá problemas de integridade de dados.

Eles também são o melhor local para auditoria, a menos que você não queira capturar todas as alterações no banco de dados (que é o problema de auditoria do aplicativo).

Os acionadores podem causar problemas de desempenho se não forem escritos com cuidado e desenvolvedores insuficientes tiverem conhecimento suficiente para escrevê-los bem. Isso é parte de onde eles conseguem seu mau rap.

Os acionadores costumam ser mais lentos do que outros meios de manter a integridade dos dados, portanto, se você puder usar uma restrição de verificação, use isso em vez de um acionador.

É fácil escrever gatilhos ruins que fazem coisas estúpidas como tentar enviar e-mails. Você realmente quer ser incapaz de alterar os registros no banco de dados se o servidor de e-mail ficar inativo?

No SQL Server, os gatilhos operam em um lote de registros. Com frequência, os desenvolvedores acham que precisam manipular somente inserções, atualizações ou exclusões de registros. Esse não é o único tipo de alteração de dados que ocorre em um banco de dados e todos os gatilhos devem ser testados sob as condições de 1 alteração de registro e muitas alterações de registro. Esquecer de fazer o segundo teste pode levar a gatilhos de desempenho extremamente fraco ou perda de integridade de dados.

    
por 06.12.2011 / 22:46
fonte
2

Outro caso de uso que eu pessoalmente encontrei é para bancos de dados que são acessados por mais de um programa. Se você quiser implementar a funcionalidade, mas não redesenhar todos os sistemas para ela, um acionador faz uma solução sensata.

Por exemplo, eu trabalhei recentemente em um banco de dados que existia anteriormente como um sistema de escritório. Quando um webapp era escrito para interagir com ele, queríamos implementar um sistema de notificação (semelhante ao stackexchange, por exemplo), que seria acionado por vários eventos, como o processamento de uma transação e assim por diante. Conseguimos implementar um gatilho para que as atualizações no back-end do escritório disparassem um gatilho para criar a notificação para o frontend e informar ao usuário que a transação foi processada pelo escritório.

    
por 24.02.2012 / 16:04
fonte
2

Uso de acionadores de banco de dados

  1. Para gerar valores de coluna automaticamente.
  2. Para impor restrições de integridade complexas.
  3. Para impor regras comerciais complexas.
  4. Para personalizar autorizações de segurança complexas.
  5. Para manter tabelas replicadas.
  6. Para auditar a modificação de dados.
por 10.03.2013 / 08:20
fonte
1

Os acionadores podem ser usados para impor restrições no banco de dados que não podem ser impostos durante a criação do esquema do banco de dados e em nenhuma instrução DML.

    
por 03.10.2012 / 07:11
fonte
0

Digamos que você precise enviar dados para um sistema de terceiros praticamente em tempo real. Sua tabela contém 950 gigabytes de dados, por isso é muito grande simplesmente empurrar a tabela inteira para o aplicativo de terceiros.

Em vez disso, você acumula alterações em uma fila. Algum programa externo, então, periodicamente enviará pequenos lotes de dados enfileirados.

O sistema tem mais de 2000 procedimentos armazenados. Você também sabe que toneladas de sql existem no código-fonte. Para garantir que a fila seja preenchida corretamente, você terá que pesquisar todos os procs e códigos armazenados e esperar que não perca nada.

Em vez disso, você pode colocar um gatilho na tabela para manter a fila atualizada. Garantido para não perder nada. Um local central. Penalidade de desempenho? Não realmente porque o impacto de preencher a fila não pode ser evitado, seja por acionamento ou externo.

Nesse cenário, eu diria que não usar um trigger é uma escolha ruim de design. Se mais tarde você quiser usar um novo método de envio de dados (digamos que a fila não está funcionando) e a interface mudar, você estará protegido se usar o gatilho. Os gatilhos são geralmente a melhor escolha. Não dê ouvidos a fanboys anti-trigger dogmáticos.

    
por 03.12.2011 / 20:18
fonte
-6

Um gatilho que envia e-mail não é necessariamente uma ideia 'estúpida'. O que é estúpido não é antecipar a interrupção do e-mail no design e lidar com isso graciosamente sem perda de dados. A parte 'estúpida' disso é realmente ruim para o tratamento inexistente de erros por desenvolvedores preguiçosos que sentem que são imunes a cometer erros.

Eu também ofereceria a observação de que um gatilho pode ser mantido simples invocando um procedimento / função armazenado que pode ser arbitrariamente complicado e que pode ser reutilizável por vários gatilhos ou outros procedimentos armazenados. É por isso que existem pacotes e bibliotecas.

O fanatismo é realmente incapacitante.

    
por 09.09.2016 / 21:08
fonte

Tags