O banco de dados aciona o mal? [fechadas]

Os gatilhos do banco de dados são uma má ideia?

Na minha experiência, eles são maus, porque podem resultar em efeitos colaterais surpreendentes e são difíceis de depurar (especialmente quando um gatilho dispara outro). Muitas vezes, os desenvolvedores nem pensam em procurar se há um gatilho.

Por outro lado, parece que se você tem uma lógica que deve ocorrer sempre que um novo FOOé criado no banco de dados, o local mais seguro é colocar um gatilho de inserção na tabela FOO.

A única vez que estamos usando gatilhos é para coisas realmente simples, como definir o ModifiedDate.

Os principais problemas com gatilhos são

• Eles são completamente globais - eles se aplicam independentemente do contexto da atividade da tabela;
• Eles são furtivos; é fácil esquecer que eles estão lá até machucá-lo com consequências não intencionais (e muito misteriosas).

Isso apenas significa que eles precisam ser usados ​​com cuidado nas circunstâncias adequadas; que na minha experiência é limitado a problemas de integridade relacional (às vezes com granularidade mais fina do que você pode obter declarativamente); e geralmente não para fins comerciais ou transacionais. YMMV.

Não, eles são realmente uma boa ideia. Se houver um problema com seus gatilhos específicos, você não os fará corretamente, mas isso geralmente significa que há um problema com sua implementação, não o conceito de gatilhos :-).

Usamos muito os gatilhos, porque coloca a atividade específica do DBMS sob o controle do banco de dados ao qual ele pertence. Os usuários de um SGBD não precisam se preocupar com esse tipo de coisa. A integridade dos dados está no próprio banco de dados, não nos aplicativos ou usuários que os utilizam. Sem restrições, gatilhos e outros recursos no banco de dados, os aplicativos devem aplicar as regras e são necessários apenas um aplicativo / usuário não autorizado ou com bugs para destruir os dados.

Por exemplo, sem gatilhos, coisas maravilhosas como colunas geradas automaticamente não existiriam e você teria que processar uma função em cada linha ao selecioná-las. É provável que isso prejudique o desempenho do DBMS, muito melhor criar a coluna gerada automaticamente no momento da inserção / atualização, pois é a única vez que ela muda.

Além disso, a falta de acionadores impediria que as regras de dados fossem aplicadas no DBMS, como pré-acionadores, para garantir que as colunas tenham um formato específico. Observe que isso é diferente das regras de integridade de dados, que geralmente são apenas pesquisas de chave estrangeira.

Ferramentas nunca são más. Aplicações dessas ferramentas podem ser más.

Concordo. Os problemas com gatilhos são pessoas, não gatilhos. Embora seja mais para olhar, mais para considerar e aumentar o ônus dos codificadores que verificam as coisas corretamente, não descartamos índices para tornar nossa vida mais simples. (Índices ruins podem ser tão ruins quanto gatilhos ruins)

A importância dos gatilhos (na minha opinião) é que ...
- Qualquer sistema sempre deve estar em um estado válido
- O código para aplicar esse estado válido deve ser centralizado (não gravado em todos os SP)

Do ponto de vista da manutenção, um gatilho é muito útil para codificadores concorrentes e problemas para os mais jovens / amadores. No entanto, essas pessoas precisam aprender e crescer de alguma forma.

Eu acho que tudo se resume ao seu ambiente de trabalho. Você tem pessoas confiáveis ​​que aprendem bem e que podem ser metódicas? Caso contrário, você aparentemente tem duas opções:
- Aceite que precisará perder a funcionalidade para compensar
- Aceite que precisa de pessoas diferentes ou que tenha melhor treinamento e gerenciamento

Eles parecem duros, e acho que são. Mas é a verdade básica, em minha mente ...

Eu acho que gatilhos não são apenas maus, mas necessários para o bom design do banco de dados. Os programadores de aplicativos pensam que os bancos de dados são afetados apenas por seus aplicativos. Eles estão frequentemente errados. Se a integridade dos dados deve ser mantida, não importa de onde a alteração ocorreu, os acionadores são um requisito e é tolice evitá-los, porque alguns programadores são etnocêntricos demais para considerar que algo diferente de seu aplicativo premiado pode estar afetando as coisas. Não é difícil projetar, testar ou solucionar problemas de um gatilho se você for um desenvolvedor de banco de dados competente. Também não é difícil determinar que um gatilho está causando um resultado inesperado se ocorrer a você (como acontece comigo) olhar para lá. Se eu receber um erro dizendo que uma tabela que não estou referenciando no meu sp tem um erro FK, Eu sei, mesmo sem pensar, que o gatilho está causando o problema e qualquer desenvolvedor de banco de dados competente. Colocar regras de negócios apenas no aplicativo é a causa número um que eu encontrei de dados incorretos, pois outros não têm idéia de que essa regra existe e a violam em seus processos. As regras centradas em dados pertencem ao banco de dados e os gatilhos são essenciais para aplicar as mais complexas.

Principalmente sim.

A dificuldade com um gatilho é que ele faz coisas "nas suas costas"; o desenvolvedor que mantém o aplicativo pode facilmente não perceber que está lá e fazer alterações que estragam tudo sem nem perceber.

Ele cria uma camada de complexidade que apenas adiciona trabalho de manutenção.

Em vez de usar um gatilho, geralmente pode ser feito um procedimento / rotina armazenado para fazer a mesma coisa, mas de maneira clara e sustentável - chamar uma rotina armazenada significa que o desenvolvedor pode examinar seu código-fonte e ver exatamente o que está acontecendo.

Os gatilhos são extremamente poderosos e úteis, há vários cenários em que um gatilho é a melhor solução para um problema.

Eles também são uma ferramenta muito boa de "hack". Muitas vezes, há situações em que você não está no controle imediato do código e do banco de dados. Se você precisar esperar 2 meses para a próxima versão principal do seu código, ainda poderá aplicar um patch ao seu banco de dados imediatamente, poderá acionar uma tabela para executar algumas funcionalidades adicionais. Quando a liberação do código for possível, você poderá substituir esse gatilho pela sua versão codificada da mesma funcionalidade, se desejar.

No final do dia, tudo é "mau" se você não sabe o que está fazendo. Decidir que os gatilhos são porque existem desenvolvedores que não os entendem é o mesmo que argumentar que os carros são maus porque algumas pessoas não podem dirigir ...

Os gatilhos têm seus usos - registrar / auditar e manter uma data de "última modificação" são dois usos muito bons mencionados nas respostas anteriores.

No entanto, um dos princípios básicos do bom design é que as regras de negócios / lógica de negócios / como você deseja chamá-lo devem estar concentradas em um único local. Colocar parte da lógica no banco de dados (por meio de gatilhos ou procs armazenados) e parte do aplicativo viola esse princípio. Duplicar a lógica nos dois lugares é ainda pior, pois eles invariavelmente ficam fora de sincronia.

Há também a questão do "princípio da menor surpresa" que já foi mencionada.

Os gatilhos são uma boa ferramenta quando usados ​​corretamente. Especialmente para auditoria de alterações, preenchimento de tabelas de resumo etc.

Agora eles podem ser "maus" se você acabar no "inferno do gatilho" com um gatilho que desencadeia outros gatilhos. Certa vez, trabalhei em um produto COTS onde eles tinham o que chamavam de "gatilhos flexíveis". Esses gatilhos foram armazenados em uma tabela quando compiladas picadas sql dinâmicas cada vez que são executadas. Os gatilhos compilados examinariam e verificariam se essa tabela tinha algum gatilho flexível para executar e, em seguida, compilar e executar o gatilho "flex". Em teoria, isso soou como uma ideia muito legal porque o produto foi facilmente personalizado, mas a realidade era que o banco de dados praticamente explodiu devido a todas as compilações que ele tinha que fazer ...

Então, sim, eles são ótimos se você mantiver o que está fazendo em perspectiva. Se for algo bem simples como auditoria, resumo, seqüenciamento automático, etc., sem problemas. Lembre-se da taxa de crescimento da tabela e de como o gatilho afetará o desempenho.

Em um nível alto, existem dois casos de uso para gatilhos1

1) Para fazer coisas "automagicamente" acontecerem. Nesse caso, os gatilhos causam um efeito colateral, eles alteram os dados de maneiras que não eram esperadas, devido à inserção, atualização ou exclusão do operador (primitivo) que foi executado e causou o disparo do gatilho.

O consenso geral aqui é que os gatilhos são realmente prejudiciais. Porque eles alteram a semântica conhecida de uma instrução INSERT, UPDATE ou DELETE. A alteração da semântica desses três operadores SQL primitivos morderá outros desenvolvedores que, mais tarde, no futuro, precisam trabalhar em suas tabelas de banco de dados que não se comportam mais das maneiras esperadas quando operadas com as primitivas SQL.

2) Para impor regras de integridade de dados, além daquelas com as quais podemos lidar declarativamente (usando CHECK, PRIMARY KEY, UNIQUE KEY e FOREIGN KEY). Nesse caso de uso, todos os gatilhos são QUERY (SELECT) para verificar se a alteração que está sendo feita pelo INSERT / UPDATE / DELETE é permitida ou não. Assim como restrições declarativas fazem por nós. Somente neste caso nós (os desenvolvedores) programamos a aplicação.

O uso de gatilhos para o último caso de uso não é prejudicial.

Estou escrevendo sobre isso em: http://harmfultriggers.blogspot.com

Conheço desenvolvedores que pensam que os gatilhos sempre devem ser usados ​​onde é a maneira mais direta de alcançar a funcionalidade que desejam e desenvolvedores que nunca o farão. É quase como um dogma entre os dois campos.

No entanto, eu pessoalmente concordo completamente com o MarkR - você pode (quase) sempre escrever um código funcionalmente equivalente ao gatilho que será mais visível e, portanto, mais fácil de manter.

Não é mau. Eles realmente simplificam coisas como

1.Logging / auditoria de alterações em registros ou mesmo esquemas de banco de dados

Você pode ter um gatilho no ALTER TABLE que reverte as alterações no seu ambiente de produção. Isso deve impedir qualquer modificação acidental da tabela.

2.Reforço da intrgridade referencial (relacionamentos de chave primária / estrangeira etc.) em vários bancos de dados

Nah, eles não são maus - eles são apenas incompreendidos :-D

Os gatilhos têm um uso válido, mas com muita frequência como um retro-hack que acaba piorando as coisas.

Se você estiver desenvolvendo um banco de dados como parte de um aplicativo, a lógica deve sempre estar no código ou sprocs que fazem a chamada. Os gatilhos levarão à dor de depuração mais tarde.

Se você entender como o bloqueio, o impasse e como os DBs acessam os arquivos no disco, o uso de gatilhos da maneira correta (por exemplo, auditoria ou arquivamento do acesso direto ao DB) pode ser realmente valioso.

Dizer que eles são maus é um exagero, mas eles podem causar malhas. Quando o disparo de um gatilho faz com que outros disparem, torna-se realmente complicado. Digamos que eles sejam problemáticos: http://www.oracle.com/technology/oramag/oracle/08-sep/o58asktom.html

Fazer lógica de negócios no Oracle com gatilhos é mais difícil do que parece devido a problemas de simultaneidade múltipla. Você não vê alterações em outra sessão até que as outras sessões sejam confirmadas.

Definitivamente, eles não são maus. Achei gatilhos preciosos durante a refatoração de esquemas de banco de dados, renomeando uma coluna ou dividindo-a em duas colunas ou vice-versa (exemplo: caso de nome / sobrenome) e ajudando na transição.

Eles também são muito úteis para auditoria.

Esta resposta se aplica especificamente ao SQL Server. (embora possa também se aplicar a outros RDBMSs que eu não tenho ideia. Eu preferiria dar como resposta aqui, mas que foi encerrada como uma bobagem disso.)

Um aspecto não mencionado em nenhuma das respostas até agora é a segurança. Como, por padrão, os gatilhos são executados no contexto do usuário que executa a instrução que aciona o gatilho, isso pode causar uma ameaça à segurança, a menos que todos os gatilhos sejam revisados.

O exemplo dado no BOL sob o título " Gerenciando a segurança do acionador " é de um usuário que cria um acionador que contém o código GRANT CONTROL SERVER TO JohnDoe ;para escalar suas próprias permissões.

Se houver efeitos colaterais, é um problema por design. Em alguns sistemas de banco de dados, não há outra possibilidade de definir um campo de incremento automático, ou seja, para um campo de ID da chave primária.

Eu acho que eles podem ser maus, mas apenas tão maus quanto qualquer outra coisa em desenvolvimento.

Embora eu realmente não tenha muita experiência com eles, eu os tive em um projeto recente em que trabalhei, o que me levou a essa conclusão. O problema que tenho com eles é que eles podem fazer com que a lógica comercial acabe em dois locais, uma biblioteca de códigos e um banco de dados.

Eu vejo isso como um argumento semelhante ao uso de sprocs. Você sempre terá desenvolvedores realmente bons em SQL gravando a lógica de negócios no banco de dados, enquanto pessoas que não são, terão sua lógica de negócios em outro lugar.

Portanto, minha regra geral é analisar qual é a estrutura do seu projeto. Se parece viável ter lógica comercial armazenada no banco de dados, pode ser útil ter gatilhos.

De fato, muitas vezes gatilhos estão sendo mal utilizados. Na verdade, na maioria dos casos, você nem precisa deles. Mas isso não os torna necessariamente ruins.

Um cenário que me ocorre em que os gatilhos são úteis é quando você tem um aplicativo herdado para o qual não possui o código fonte e não há como alterá-lo.

A idéia de gatilhos não é má; limitar o aninhamento de gatilhos é ruim.