Linguagem De Programação Comercial

FACULDADE ANHANGUERA EDUCACIONAL

- FAC 02 -

DISCIPLINA

PROGRAMAÇÃO EM BANCO DE DADOS

PROF. MARIO

PROGRAMAÇÃO EM BANCO DE DADOS

CAMPINAS, SP

OUTUBRO DE 2013

FACULDADE ANHANGUERA EDUCACIONAL

- FAC 02 -

DISCIPLINA

PROGRAMAÇÃO EM BANCO DE DADOS

PROF. MARIO

TADS- ANALISE DESENV. DE SISTEMAS

PROGRAMAÇÃO EM BANCO DE DADOS

CAMPINAS, SP

OUTUBRO DE 2013

INTRODUÇÃO À TRIGGERS

Há tempos que venho estudando sobre esse tipo de implementação voltada primeiramente ao SQL Server e agora também, podendo ser utilizada no MySQL em sua versão de número 5 ou posterior.

Embora muitos desenvolvedores e entusiastas digam que eles são boas práticas dentro de bancos de dados, resolvi estudar a fundo, para deixar aqui a minha posição sobre o assunto.

Existem várias maneiras de tratarmos ou nos dirigirmos a esse tipo de implementação. Podemos chamar de TRIGGER, gatilhos ou disparadores. Neste artigo, usarei o termo mais conhecido entre administradores de Banco de Dados, TRIGGER.

Todos os scripts que aqui serão exibidos foram testados em um ambiente Windows XP Professional, rodando SQL Server 2000 Service Pack 4.

CONCEITOS:

• O que são TRIGGERS;

• Usos e aplicabilidade dos TRIGGERS;

• Considerações e boas práticas em relação aos TRIGGERS;

• Quando e como usá-los;

Primeiramente, vamos abordar o conceito central de TRIGGERS:

Um trigger é um tipo especial de procedimento armazenado, que é executado sempre que há uma tentativa de modificar os dados de uma tabela que é protegida por ele.

- Associados a uma tabela

Os TRIGGERS são definidos em uma tabela específica, que é denominada tabela de TRIGGERS;

- Chamados Automaticamente

Quando há uma tentativa de inserir, atualizar ou excluir os dados em uma tabela, e um TRIGGER tiver sido definido na tabela para essa ação específica, ele será executado automaticamente, não podendo nunca ser ignorado.

- Não podem ser chamados diretamente

Ao contrário dos procedimentos armazenados do sistema, os disparadores não podem ser chamados diretamente e não passam nem aceitam parâmetros.

- É parte de uma transação

O TRIGGER e a instrução que o aciona são tratados como uma única transação, que poderá ser revertida em qualquer ponto do procedimento, caso você queria usar “ROLLBACK”, conceitos que veremos mais a frente.

Orientações básicas quando estiver usando TRIGGER.

- As definições de TRIGGERS podem conter uma instrução “ROLLBACK TRANSACTION”, mesmo que não exista uma instrução explícita de “BEGIN TRANSACTION”;

- Se uma instrução “ROLLBACK TRANSACTION” for encontrada, então toda a transação (o TRIGGER e a instrução que o disparou) será revertida ou desfeita. Se uma instrução no script do TRIGGER seguir uma instrução “ROLLBACK TRANSACTION”, a instrução será executada, então, isso nos obriga a ter uma condição IF contendo uma cláusula RETURN para impedir o processamento de outras instruções.

- Não é uma boa prática utilizar “ROLLBACK TRANSACTION” dentro de seus TRIGGERS, pois isso gerará um retrabalho, afetando muito no desempenho de seu banco de dados, pois toda a consistência deverá ser feita quando uma transação falhar, lembrando que tanto a instrução quanto o TRIGGER formam uma única transação. O mais indicado é validar as informações fora das transações com TRIGGER para então efetuar, evitando que a transação seja desfeita.

- Para que um TRIGGER seja disparado, o usuário o qual entrou com as instruções, deverá ter permissão de acessar tanto a entidade e consequentemente ao TRIGGER.

Usos e aplicabilidade dos TRIGGERS

• Impor uma integridade de dados mais complexa do que uma restrição CHECK;

• Definir mensagens de erro personalizadas;

• Manter dados desnormalizados;

• Comparar a consistência dos dados – posterior e anterior – de uma instrução UPDATE;

Os TRIGGERS são usados com enorme eficiência para impor e manter integridade referencial de baixo nível, e não para retornar resultados de consultas. A principal vantagem é que eles podem conter uma lógica de processamento complexa.

Você pode usar TRIGGERS para atualizações e exclusões em cascata através de tabelas relacionadas em um banco de dados, impor integridades mais complexas do que uma restrição CHECK, definir mensagens de erro personalizadas, manter dados desnormalizados e fazer comparações dos momentos anteriores e posteriores a uma transação.

Quando queremos efetuar transações em cascata, por exemplo, um TRIGGER de exclusão na tabela PRODUTO do banco de dados Northwind pode excluir os registros correspondentes em outras tabelas que possuem registros com os mesmos valores de PRODUCTID excluídos para que não haja quebra na integridade, como a dito popular “pai pode