Programação / MariaDB

Aprenda a criar Triggers e entenda o seu comportamento no MariaDB

Triggers são gatilhos disparados automaticamente assim que determinada ação é executada dentro do banco de dados.

Por Gustavo Web

Publicado por Gustavo Web
em 28/09/2018 às 10h25

Lista VIP UpInside

Entre para nossa lista VIP e receba vídeo aulas, artigos e tutoriais exclusivos e com prioridade

  QUERO ENTRAR

Aula exclusiva UpInside Play

Acessar aula no Play

Compartilhe:

Bora entender como funciona a criação de gatilhos no MariaDB? E para não ficar nenhum tipo de dúvida, ainda fazer isso com base na documentação.

Salve salve WebMaster, Gustavo Web aqui e hoje vamos ver como criar um gatilho bastante simples no banco de dados para que possa executar uma outra ação automaticamente.

Se você não sabe o que é trigger, vamos para uma breve explicação:

Esse recurso, faz com que ao receber um INSERT, UPDATE ou DELETE em determinada tabela do seu banco, você possa disparar uma outra query.

O uso desse recurso são variados... Mas no geral, muitos desenvolvedores usam para gerar uma "camada" de log! Quando receber uma alteração na tabela de usuário por exemplo, verificam os campos que foram alterados e salva isso numa tabela a parte para ter controle de quando foi feita a alteração, quais campos mudaram...

Esse tipo de ação, no meu ponto de vista é algo que deve ser tratado pela aplicação. Gatilho no banco de dados, dependendo do volume de dados, estrutura de tabelas, quantidade de tabelas, transações... Pode ser que acabe se tornando o principal ponto de gargalo dentro da sua modelagem.

E o curioso disso é que você só vai identificar que a trigger está sendo um gargalo no seu banco, quando for tarde demais para passar essa responsabilidade para a aplicação. Não que seja impossível, óbvio, mas já vai estar muito bem entranhado no seu schema.

Isso não quer dizer que não pode ser utilizado em nenhum momento... Muito pelo contrário, em determinadas situação fazer o uso de trigger faz com que esteja centralizado a regra de negócio para a alteração de um campo ou contabilidade de um valor.

Quando usar

Você pode partir da seguinte premissa: "Se eu não tiver nenhuma consulta dentro da trigger, ou se a consulta não atrapalhar a performance da execução eu posso usar!"

Com isso você pode imaginar, que a consulta que você tem que fazer dentro da trigger não seja pesada. Mas primeiro analise os principais pontos de uma estratégia de performance:

Quantidade de registros: Não precisa se preocupar com 1000, 5000, ou 10000 registros. Bancos de dados foram feitos para trabalhar com milhões deles... Nesse caso você está bem longe de uma quantidade expressiva a ponto de dar um gargalo. Isso é claro que depende da infraestrutura que você está dedicando para o banco.

- Expurgar dados: Você precisa trabalhar com registros a mais de 3 anos na sua base? Não poderia estudar a possibilidade de pegar esses registros e jogar para uma outra tabela para deixar a principal mais enxuta? É claro que os dados não serão mostrado em relatórios e nas pesquisas, mas numa urgência você pode recuperá-los facilmente.

- Índices: O campo que você está usando como filtro é um índice? Se não for, ele pode ser um? Índices estão diretamente ligados ao espaço em disco ocupado... E também não adianta criar índice de todas as suas colunas.

Esses são alguns pontos a serem observados quando vai adicionar trigger na sua tabela

Material de Apoio

Não precisamos de nenhum repositório no Git para isso... Vamos simplesmente seguir um tutorial bem básico disponível dentro da própria documentação que você pode consultar através desse link!

Feedback

Me fala aqui abaixo nos comentários se você já conhecia esse recurso e se conseguiu aplicar aí na sua base de testes.

Compartilhe:

Em Programação:

Deixe seu comentário: