Los Triggers de SQL pueden ser los causantes de muchos problemas si no se tienen en cuenta las mejores prácticas a la hora de aplicarlos.
Estos pueden ser muy útiles cuando hay que forzar una integridad referencial y un desastre no si no son correctamente construidos; y a menudo, difíciles de detectar.
Más allá de una auditoria, realmente no son necesarios ya que la lógica del mismo se puede aplicar sobre los procedimientos o a través de alguna FK que reemplaza su funcionalidad manteniendo un único punto de trabajo sobre el dato.
En mi tiempo de DBA varias veces me he encontrado dando soporte a Triggers que realmente no deberían existir. Estos son los problemas más frecuentes que encuentro:
1. Los Triggers no son más lentos que un procedimiento almacenado u otro objeto de SQL, el problema es el uso y la lógica que contienen. 2. Son objetos compilados y responden como tal.
3. No apliques la lógica de negocios en un Trigger, básicamente la lógica va en los procedimientos 4. KIS, Keep It Simple. No hagas magia en un Trigger.
5. Evita y elimina la recursividad de Triggers, SQL Server posee hasta 32 niveles
Para deshabilitar los Triggers recursivos, podes hacerlo así:
--Ejemplo 1 sp_configure 'nested_triggers',0 GO RECONFIGURE GO -- Ejemplo 2 ALTER DATABASE DB_NAME SET RECURSIVE_TRIGGERS ON | OFF
Basado en la nota de sqlserver-dba.com