Recentemente, fizemos uma alteração para criar restrições com base na lógica usada anteriormente em procedimentos armazenados, e parte disso incluiu o uso de INSTEAD OFgatilhos para centralizar a lógica.
A lógica é geralmente simplista:
- O procedimento armazenado contém uma instrução INSERT (ou UPDATE) em uma exibição, que possui gatilhos INSTEAD OF INSERT/UPDATE
- O gatilho contém a lógica real -- geralmente duas instruções, lidando com INSERT/UPDATE de um registro em uma tabela principal e uma (ou mais) tabelas de suporte (incluindo integridade referencial).
O problema é quando algo como uma restrição CHECK é atingido na instrução do gatilho. A transação é despejada e tudo é revertido. Estou pensando em duplicar a restrição CHECK/etc nos procedimentos armazenados incorretos para validar antes da execução do gatilho - existe alguma alternativa?
Provavelmente não. A violação de uma restrição declarativa sempre gerará um erro e impedirá que a transação cometa gravações que violariam as restrições. O objetivo das restrições do banco de dados - verificações, chaves estrangeiras, únicas, etc. - é que elas impedem que dados inválidos sejam registrados no banco de dados, abortando gravações que violarão as restrições. A violação de restrição gera um erro e reverte a transação.
Se você deseja que a transação falhe normalmente, você terá que lidar com a exceção ou pré-validar os dados antes de tentar escrevê-los. Neste último caso, você terá que substituir as validações nos procedimentos armazenados ou implementar a validação no aplicativo.