Trigger, SIM ou NÃO?

[Maffra]

Pessoal,

Gostaria de abir um tópico sobre esse assunto que ao meu ver é polêmico: Usar ou não usar Trigger?

A minha opinião é para não usar, ou melhor, só usar em caso extremo, só em último caso. Mesmo que eu a crie vou trabalhar dia a dia para tirá-la. Vou pensar em 1000 possibilidades de tratar via aplicativo do que criar uma Trigger, principalmente se é possível tratar pelo sistema.

Gostaria de criar uma lista no final para saber se é mais benéfico usar Trigger ou não. Pra começar vou colar um trecho do que é uma trigger:

Triggers

Uma Trigger (ou Gatilho) é um objeto no banco de dados, assim como uma tabela, um campo ou um índice que está presente na maioria dos sistemas de gerenciamento de banco de dados (SGBD). Por definição, uma Trigger nos SGBD é um procedimento que é disparado quando algum evento acontece no banco.

A Trigger não é chamada nem é executada, ela é disparada automaticamente como consequência de alterações em tabelas no banco de dados: INSERT, DELETE e UPDATE. Normalmente esse mecanismo é utilizado para manter a integridade dos dados realizando alterações de dados de uma forma sistemática. Além das Triggers, alguns SGBD possuem outros mecanismos de integridade, como Constraint e Assertion.

Uma Trigger é dividida em três partes:

Evento: tipo de evento que será executado

Condição: necessidade de executar ou não a ação

Ação: sequência de comandos que serão executadas

Outra utilização das Triggers está o processo de replicação (cópia) de dados, armazenando os dados de forma redundante para evitar associações frequentes de tabela e a implantação de regras de negócios complexas.

Como cuidado especial na criação de Trigger está o fato que é possível que ao realizar alguma ação outra Trigger seja executada. Esse comportamento que é útil para criar o efeito cascata pode se mal elaborado, criar um loop no banco de dados.

http://www.datasuldirect.com.br/flash/news/Edicao182.htm

POR QUE NÃO USAR TRIGGER

1 - Ao adotar Trigger resultará na quase impossibilidade de migração de banco de dados. Trigger utiliza linguagerm proprietária.

2 - Trigger é uma linguagem alienígena na aplicação. O sistema possui regras de negócio que disparam ações no banco de dados e você quer mudar o processo pois não se adpata ao sistema. Não é melhor adaptar o seu processo ou solicitar uma mudança pra empresa do software?

3 - Queda de perfmormance. Por mais que você utilize condições para sua Trigger ser rodada ela será chamada para fazer o teste.

4 - Trigger é centralizadora, não fica a cargo do usuário. O usuário não pode decidir se usa ou não. Tá na regra de quem desenvolveu. Se colocar no aplicativo o usuário pode ter domínio sobre o mesmo.

5 - Em um ambiente de segurança, data center por exemplo, dependerá de um DBA responsável para criar, alterar ou apagar a Trigger, visto que esses comandos são DDL.

6 - As atualizações de versões dos sistemas e de banco de dados (incluindo conversões do RM) não olham as Triggers. É um trabalho a mais para administrar e se não testar antes sua produção pode parar.

7 -

POR QUE USAR TRIGGER

1 -

Obrigado,

[Edson Silva]

Eu também sou contra o uso de trigger, pois voce perde um tempo analisando e sem contar que se você sair do projeto e não tiver uma boa documentação, pobre que quem assumir.

[Fauze Quedas]

Olá, também sou contra as trigger's. Sempre que há uma alteração de versão, elas precisam ser revisadas, pois acabam sendo apagadas ou tendo funções internas suprimidas nas novas versões.

Como nosso colega comentou, mesmo estando bem documentado, geralmente o período de revisão e operacionalização, acabam esgotando a paciência de qq um na empresa, e a culpa cai sempre no responsável pelo sistema.

Prefiro trabalhar com stored procedure, que não ficam atreladas a uma tabela, e podem ser rodadas por um relatório simples, abastecendo tabelas provisórias.

[Eudemar]

Olá pessoal!

Quando não tem jeito mesmo, eu utilizo triggers que disparam stored procedures (SP), dentro da trigger, coloco somente o código necessário para gerar a lista de parâmetros de uma chamada de SP, normalmente a estrutura das minhas triggers possui um "select from inserted/del/up..." que me traz todos os parâmetros, e uma chamada à SP.

Desta forma, é posível fazer a validação da informação antes da chamada da SP, minimizando o impacto no BD

Se mudar algo que vá impactar no código escrito, fica mais fácil isolar e corrigir o problema. Sem contar que depurar uma SP é muito mais tranqüilo que uma trigger, estas, em algumas circunstâncias são impossíveis de serem depuradas... sem contar que para desenvolver a SP não é necessário o disparo de uma trigger, somente uma chamada.

acho que é isto, se lembrar de algo mais, eu grito

um abraço.

[Alexandre Gondim]

Bom dia!

Acho que todos nós tivemos algumas situações que nos levam a não utilizar a TRIGGER. Meu caso foi o seguinte: Como o sistema não possui um controle de histórico de cheque devolvido, fiz um controle a parte, criando uma tabela, sendo alimentada a cada vez que o cheque fosse devolvido, enfim ficou bom e o cliente gostou muito. Aí quando mudou da versão 7 para versão 10 foi tudo por água abaixo, a TRIGGER simplesmente parou de funcionar, conferi os campos, relacionamentos e não consegui por este controle normal.

Então usar TRIGGER somente no último caso!

Obrigado

At,

[Mauricio J. T.]

Eu sou a favor das Triggers desde que fazem parte do projeto inicial A vantagem é que ela realiza a maioria das regras de negocio no proprio banco, poupando assim muita transferencia de dados .Isso nao ocorre no caso do Corpore RM, talvez porque no inicio os desenvolvedores nao estavam muito a par da facilidade. No corpore, nao existe nenhuma trigger, enquanto em outras soulções, a maioria das transações eram feitas por elas

[Fábio Maia]

Só em último caso. Regra de negócio tem que estar na aplicação. Mudou a regra basta alterar a parametrização na aplicação e não refazer o código na trigger.

[ ]

[Mauricio J. T.]

Estou pensando de uma maneira mais ampla, e nao so CorporeRM.Se voce colocar a maioria das regras de negocios no banco voce consegue mais escalabilidade, seja ele CorporeRM , Microssiga , etc. As regras basicas estao no banco.

[Maffra]

Sistema bom não tem só escalabilidade, tem que ter também portabilidade e acho q a maioria dos problemas das triggers estão na portabilidade... A portabilidade tem como subcaracterísticas: adaptabilidade, capacidade para ser instalado, conformidade e capacidade para substituir.

Vamos lá gente... o assunto é bom!!!

[Mauricio J. T.]

a maioria dos sistemas em trez camadas, usa triggers, pois resolve praticamente tudo no servidor. como se trata de trafego em ASP, se deixar para o front end, fica muito lento quando ha muitas solicitações de respostas...

[Nelson Borges]

Bom, eu sou a favor do webservices, ou melhor do WCF (Windows Comunication Foundation), para modelos N-Tier..rs

Brincadeiras a parte, quanto ao uso de Triggers não vejo nenhum problema desde que seja feito com cuidado e realmente em uma necessidade (por isso existe o recurso). As PK e FK do banco utilizam triggers para manter a integridade do mesmo. Creio que hoje possuimos vários recursos que nos fazem usar cada vez menos triggers, um bom exemplo foi o que Eudemar disse sobre o uso de Triggers com SP, isso com certeza terá maior administração e menor manutenção no código. Por isso Mauricio me desculpe, mas acho que você está equivocado quando fala a as Triggers fazem parte do modelo de negócio.

Resumindo : As Triggers são uma ótima funcionalidade, porém seu uso é restrito a necessidade.

Atenciosamente,

_______________________

Nelson Borges

Developer Microsoft .NET && SQL Server

[Emanuel Peixoto]

O objetivo das triggers é bem claro, é dar suporte as regras de negócio independente da aplicação, ou seja, é um recurso fenomenal. No caso, da aplicação revove-la quando são realizados os updates de versões isso é uma falha do sistema.

Ora, se o banco de dados é um componente independente da aplicação, o que no máximo poderia acontecer era a alteração e adição de objetos nunca remoção, pois, o banco de dados não é proprietário do sistema X, Y ou Z, ele é independente.

imaginem a situação:

Um grande companhia compra a solução RM, e implanta um recurso de replicação de dados dos sistemas entre a matriz e as filiais baseada em de triggers, num sei nem se a RM já possui um recurso para esse tipo de situação...

se, quando eu fizer uma atualização de versão e isso me gerar incidentes na infra-estutura de banco de dados e nas regras de negócio devido ao sistema remove-las, isso é certo? O banco de dados não é indepenente? o sistema está respeitando isso?

"Usar ou não triggers...." vai depender da necessidade, ora se eu escolher usar triggers e se dessa forma for mais flexivel, rápido de desenvolver ou até mesmo realizar operações de integração entre sistemas de forma que de outro jeito não iria funcionar, porque não usar?

SIM, ao uso de triggers.

Editado 28 de Outubro de 2008 por Emanuel Peixoto

[andreluis1411]

Sinceramente, cada um tem um porquê para utilizar ou não triggers, mas todas eles se resumem a uma única razão: NECESSIDADE.

Sou a favor de triggers quando existem processos que o sistema não tem, ou mesmo quando existem processos que a RM não implementa no Corpore.

[Mauricio J. T.]

Ainda guardo minha posição , pois se vc fizer a maioria das transações direta no banco, vc ganha em performance , segurança e melhor distribuição no trafego das informações em toda a rede, pois nao seria o front end de cada um com sua devida velocidade, tanto de processamento quanto no trafego.Seria centralizado direto no servidor, deixando assim as tarefas menos criticas para serem executadas nos devidos front end.

[Eudemar]

Pessoal,

Como programador, sempre vejo tais discussões; qual linguagem é a melhor? qual é a melhor técnica, recursos: utilizá-los ou não? eis a questão...

Triggers são Sensacionais!

Triggers são Horríveis!

o uso de qualquer técnica tem seus prós e contras, cada uma deve ser utilizada de acordo com a necessidade do momento, portanto, a afirmação acima é totalmente verdadeira, o que deve ser utilizado na verdade é o bom senso. Não adianta eu ter um super-bam-bam-bam-hitec-servidor, concentrando todas as transações e processamento, quando na minha máquina cliente eu não consigo rodar um editor de textos decente, pois não há capacidade de processamento local.

Eu defendo a filosofia da web 2.0, nada mais será centralizado, tudo será distribuído, o processamento e o armazenamento. Na minha opinião, os SGBD deveriam ser somente isto, um repositório seguro e confiável de informações, que não extrapolassem sua função invadindo o território da programação e vice-versa, digo isto, pois é muito mais fácil adquirir portabilidade quando se trata de comunicação (p/ ex.: Linguagem-SGDB), desta forma, se for realmente necessário, fica fácil mexer no banco.

E sem dúvida, somente utiliza-se “recursos extras” quando não há alternativa menos traumática, deve-se desencorajar fortemente a POG nos ERP existentes...

[Eudemar]

Só para ficar claro, o que o Maurício disse eu faço coro, transação de banco é lá que deve ser feita. Um processo que gera outro, isto sim, deve ser controlado no aplicativo

[Jair - Fórmula]

Eu também acho que se possível, não deve ser feita no banco não. O melhor é fazer certas operações diretamente no aplicativo.

O mais problemático é, quando o sistema faz qualquer mudança em tabelas, tem que ser revisto todo e qualquer trigger que fora colocado no banco.

EU USO SIM, e recomendo, mas precisa ter cuidado, pois, um trigger que dê algum erro interno pode provocar um erro na aplicação, ai, algo que tava funcionando perfeitamente, que passa a dar um erro, é um Deus nos acuda pra achar onde está o problema.

Sobre a questão de processamento, o que eu acho é que, no server, é que tem que ser mais pesado, já que nas estações, em geral, não se tem uma máquina mais potente.

Bom, tá ai minha opinião.