Los triggers son una de las herramientas más potentes de SQL Server, pero también una de las más incomprendidas. Funcionan como un código que se ejecuta automáticamente cuando ocurre un evento en una tabla, y saber distinguir cuándo son la solución correcta marca la diferencia entre una base de datos robusta y una llena de efectos secundarios ocultos.
¿Qué es un trigger y cómo funciona en SQL Server?
Un trigger se asocia a una tabla y a uno o más eventos: insert, update o delete [0:30]. SQL Server lo ejecuta automáticamente usando dos modalidades: after (después del evento) o instead of (en lugar del evento).
Para entender los datos que maneja un trigger, existen dos tablas especiales:
- inserted: contiene las filas nuevas en un insert y los valores nuevos en un update.
- deleted: contiene las filas eliminadas en un delete y los valores anteriores en un update.
En un insert, la tabla deleted está vacía. En un delete, la tabla inserted está vacía. En un update, ambas tablas tienen datos: deleted con los valores previos e inserted con los valores actualizados [1:07].
¿Cómo crear un trigger de auditoría paso a paso?
El caso de uso más válido para un trigger es la auditoría: registrar quién cambió qué y cuándo [1:35]. Para implementarlo se necesitan dos elementos: una tabla de auditoría y el trigger que la alimenta.
¿Cómo se estructura la tabla de auditoría?
Primero se crea una tabla llamada AuditoriaPedidos con campos como el ID de auditoría, el pedido ID, la acción realizada (insert, update o delete), el estado anterior, el estado posterior, el usuario y la fecha [1:45].
¿Cómo se define el trigger sobre la tabla pedidos?
El trigger se crea con la sentencia CREATE TRIGGER asociado a la tabla Pedidos, configurado con AFTER INSERT, UPDATE, DELETE [2:20]. Dentro del cuerpo del trigger:
- Se inicia con la palabra clave
BEGIN.
- Se utiliza
SET NOCOUNT ON para evitar mensajes innecesarios de filas afectadas.
- Se ejecuta un
INSERT INTO AuditoriaPedidos que selecciona datos de las tablas inserted y deleted usando alias I y D respectivamente [3:10].
- Una expresión
CASE determina si la operación fue un insert, un update o un delete, verificando la existencia de registros en cada tabla especial [3:40].
¿Cómo verificar que el trigger funciona correctamente?
Al ejecutar un UPDATE sobre la tabla Pedidos cambiando el estado a cancelado, la tabla AuditoriaPedidos registra automáticamente la acción, el valor anterior, el valor posterior, el usuario y la fecha exacta [4:30]. Cada cambio subsiguiente genera un nuevo registro de auditoría con todo el historial de modificaciones [5:10].
¿Cuándo no se deben usar triggers en SQL Server?
A pesar de su utilidad, los triggers tienen limitaciones importantes que los hacen problemáticos en varios contextos [5:50]:
- Se ejecutan una vez por statement, no por fila. Si un update afecta 10 000 filas, las tablas inserted y deleted contendrán 10 000 registros que el trigger debe manejar con operaciones complejas.
- Son invisibles para los desarrolladores de software. Cuando algo falla, el error proviene de un lugar que nadie estaba revisando.
- Un trigger mal diseñado, anidado o recursivo puede causar bucles infinitos. SQL Server permite hasta 32 niveles de anidación [6:25].
Hay situaciones específicas donde nunca se deben usar:
- Para lógicas de negocio complejas: esa responsabilidad pertenece a la aplicación o a los procedimientos almacenados.
- Para validaciones que se pueden resolver con constraints en la definición de la tabla, lo cual resulta mucho más eficiente [6:50].
- Para replicar datos entre tablas en tiempo real: existen mejores mecanismos.
- Para cálculos que pueden hacerse en una consulta o mediante columnas calculadas [7:05].
El criterio es claro: los triggers son una herramienta legítima para auditoría e integridad de datos. Para lógica de negocio, los procedimientos almacenados son el lugar correcto.
¿Ya implementaste tu trigger de auditoría sobre la tabla clientes? Comparte tus resultados y las pruebas con update y delete en los comentarios.
