Eu sei que os gatilhos podem ser usados para validar os dados armazenados para manter o banco de dados consistente. No entanto, por que não executar a validação de dados no lado do aplicativo antes de armazená-los no banco de dados?
Por exemplo, armazenamos clientes e queremos executar alguma validação que não pode ser feita facilmente no nível DDL. https://severalnines.com/blog/postgresql-triggers-and-stored-function-basics
Outro exemplo é a auditoria.
Atualizar
Como gatilhos e transações de banco de dados funcionam juntos. Por exemplo, se eu gostaria de executar a validação dos dados que estão sendo inseridos. Isso é feito dentro de uma transação. O que acontece antes: a transação é confirmada ou o gatilho é executado?
database
database-design
postgres
Yan Khonski
fonte
fonte
However, why not perform validation of data on the application side before storing them into the database?bem, esses dois não são mutuamente exclusivos. É provável que você valide coisas diferentes dos dois lados. Embora as validações no lado do aplicativo sejam centradas nos negócios, as validações no banco de dados são mais centradas nos dados. Pense em um banco de dados alimentado por vários e diferentes aplicativos.Respostas:
Depende do tipo de sistema de aplicativos que você está construindo:
se você estiver criando um sistema centralizado em aplicativos que contenha apenas um aplicativo principal, com um banco de dados dedicado especificamente para esse aplicativo e, idealmente, uma equipe responsável por desenvolver aplicativos e bancos de dados lado a lado, poderá manter toda a lógica de validação e também auditar lógica dentro do aplicativo.
O principal benefício disso é que você não precisa distribuir a lógica de negócios entre aplicativo e banco de dados; portanto, manter e evoluir o sistema geralmente fica mais fácil. Como bônus, você não vincula muito o aplicativo a um tipo específico de fornecedor de DBMS ou DBMS. Essa abordagem é obviamente necessária se seu aplicativo quiser usar um sistema de banco de dados leve que não forneça gatilhos.
Se, no entanto, você criar um sistema no qual muitos aplicativos diferentes compartilham um banco de dados comum, e não é possível prever antecipadamente quais aplicativos serão gravados no futuro ou quais equipes desenvolverão aplicativos para preencher dados no banco de dados no futuro. é melhor que seu banco de dados seja responsável por garantir o máximo de consistência de dados possível. E é aí que os gatilhos são realmente úteis. Em sistemas maiores, as restrições referenciais geralmente não são suficientes para isso, mas um gatilho que chama um procedimento armazenado pode implementar quase qualquer tipo de validação necessária.
Outro motivo para o uso de gatilhos pode ser o desempenho: em modelos de dados complexos, não é incomum encontrar regras de consistência complexas que exigem o uso de muitos dados adicionais que não fazem parte do conjunto de trabalho atual disponível no aplicativo cliente. Transferir todos esses dados pela rede primeiro para possibilitar a validação no lado do cliente pode ter um impacto notável no desempenho.
Consulte também este post antigo do SE: Application Logic Vs DB Triggers para limpeza de banco de dados
Portanto, decida por si mesmo que tipo de sistema você está construindo e poderá tomar uma decisão fundamentada se os gatilhos forem a ferramenta certa para o seu caso ou não.
fonte
Eu acho que a pergunta é sobre responsabilidade pela qualidade dos dados.
A resposta depende de como você vê o sistema.
Se você vê o banco de dados como um serviço independente, distinto e autônomo separado do aplicativo, o banco de dados é responsável por garantir a consistência e a qualidade dos dados que ele contém. Essencialmente, porque esse banco de dados pode ser usado por um aplicativo diferente, não pode contar com o segundo aplicativo com os mesmos comportamentos de consistência e qualidade. Nessas circunstâncias, o banco de dados precisa ser projetado para expor uma API e um comportamento autônomo. Nesta visão, existem pelo menos dois aplicativos, um deles é o banco de dados e o outro é o aplicativo que o utiliza.
Por outro lado, o banco de dados pode ser considerado uma forma complicada de arquivo que está sob o controle direto e total do aplicativo. Nesse sentido, o banco de dados passa a ser uma pura ferramenta de serialização e navegação de documentos. Ele pode fornecer alguns comportamentos avançados para dar suporte a consultas e manutenção de documentos (como JSON ou ferramentas XML), mas, novamente, não é necessário (como a maioria dos fluxos de arquivos). Nesse caso, é de inteira responsabilidade do programa manter o formato e o conteúdo corretos no arquivo. Nesta visão, há um aplicativo.
Nos dois modos de exibição, a próxima pergunta é como dar suporte ao uso do banco de dados como um arquivo sofisticado ou como um serviço separado. Você pode conseguir isso:
Cada um vem com seus próprios prós / contras e dependerá das restrições arquiteturais do ambiente em que o sistema opera.
Independentemente de qual visão você adote, sempre vale a pena validar os dados nos limites.
A quantidade de validação garantida em cada limite depende de quanto é arriscado não validá-lo.
fonte
Não, você nunca deve usar gatilhos para validar.
O banco de dados é responsável apenas por sua própria integridade. Qualquer usuário enfrentando validação deve ser realizado pelo seu aplicativo.
Os bancos de dados executam três níveis de validação para integridade. O primeiro é a validação em nível de campo. Um campo pode ser obrigatório, se não houver valor (nulo), será um erro. Também pode ser uma restrição de verificação; um domínio tem um número enumerado de valores.
Em segundo lugar, existem relações entre tabelas. Em uma tabela, você armazena uma ou mais chaves estrangeiras, relacionando esta tabela com outras tabelas e exigindo que os valores sejam chaves válidas para a "outra tabela". Pense em um banco de dados de endereços, onde suportamos endereços de diferentes países. Uma chave de país em um endereço deve apontar para um país conhecido. Se os dados (por exemplo, um código postal) são válidos, não é uma preocupação dessa verificação de integridade.
Terceiro e mais complicado são os gatilhos. Como regra geral, eles devem abordar (trocadilhos não intencionados) as regras de integridade que são condicionais. Para voltar ao exemplo de endereço: se um país não tiver códigos postais, seria um problema se um país nesta lista tivesse um código postal. Portanto, a verificação seria: se este país não tiver códigos postais, o campo do código postal deverá ser nulo.
A validação é a preocupação do aplicativo. O fato de um código postal alemão consistir em apenas dígitos é uma verificação que o aplicativo deve fazer, não o banco de dados. Como a linha é fina, você pode precisar pensar / discutir em alguns casos, se algo deve estar em um gatilho (proteger a integridade do seu banco de dados) ou no aplicativo (validação voltada para o usuário).
fonte
A auditoria é um exemplo clássico do uso de gatilhos efetivamente. Encontrei alguns erros cometidos pelo testador (movendo um cliente de um nível de serviço para outro) graças a uma tabela de auditoria que foi implementada por gatilhos. Eu recomendo o uso de gatilhos para auditoria.
A validação pode ser feita no nível de front-end, mas vi erros estranhos no banco de dados que eu lidei (pessoas que nasceram em 3000 etc.) e, como alguns deles, eu me recomendo, recomendo ter uma camada extra de validação no banco de dados, apenas por precaução. Obviamente, esses tipos de erros podem ser evitados com restrições de verificação e muitas vezes são mais eficazes (no MS SQL, eles são o método preferido; sempre verifique a documentação).
fonte
Como a questão é se realmente precisamos de gatilhos para bancos de dados relacionais, aqui estão alguns outros casos de uso em que usar gatilhos:
instead of. Com isso, é possível inserir, atualizar e excluir entradas de uma exibição. Os gatilhos podem espalhar essas ações em várias tabelas. Essa é uma maneira de disponibilizar uma exibição restrita sem expor os detalhes das tabelas subjacentes.Como uma desvantagem, a lógica comercial é distribuída entre as camadas e essa é uma grande desvantagem para manutenção. Como outro autor escreveu, é um limite fino entre aplicativo e banco de dados e a escolha nem sempre é clara. Minha opinião pessoal é que os gatilhos colocam um fardo para os desenvolvedores. Eles podem economizar tempo em desenvolvimento. Definitivamente, eles aprimoram a experiência do usuário porque aumentam o desempenho em conexões de rede lentas.
fonte