Los triggers suelen empezar como una buena idea. Y muchas veces lo son. Permiten automatizar tareas, mantener trazabilidad, completar datos, aplicar reglas de negocio o reaccionar en tiempo real a determinados cambios sin depender de que la aplicación haga todo bien.

El problema es que un trigger casi nunca vive solo. Y con el tiempo, lo que empezó como una ayuda puntual puede acabar convirtiéndose en una capa paralela de lógica que nadie controla del todo.

El trigger aislado no suele ser el problema

Un trigger para auditar cambios. Otro para normalizar datos. Otro para recalcular estados. Otro para corregir una urgencia funcional. Otro porque no daba tiempo a rediseñar el flujo completo.

Cada uno, por separado, parece razonable. El problema aparece cuando el sistema acumula años de pequeñas decisiones locales y nadie conserva ya una visión global de lo que se dispara, cuándo se dispara y qué consecuencias arrastra.

Ahí empieza la deuda técnica seria. No la teórica. La que un día te explota en producción.

El verdadero riesgo: la cascada que nadie vio venir

Hace años ya escribí sobre triggers desde otro ángulo en DB2: Los triggers, haciendo el trabajo sucio, y sigo pensando que son una herramienta potentísima. Precisamente por eso conviene no perderles el respeto.

Hace poco me encontré con un caso bastante ilustrativo. No empezó con una caída espectacular. No hubo una alarma clarísima. No apareció un error evidente que señalara directamente la causa.

Lo que apareció fue algo mucho más traicionero: una cadena de efectos cada vez más pesada, más bloqueante y más difícil de explicar.

El patrón era el de siempre:

• una actualización dispara un trigger,
• ese trigger modifica otros datos,
• esa modificación activa otro trigger,
• y el proceso vuelve a entrar en una cadena de escrituras que nadie había acotado bien.

A veces eso acaba en un bucle infinito puro. Otras veces no llega a infinito, pero sí genera una cascada suficientemente grande como para degradar el sistema, bloquear recursos y volver opaca la causa real del problema.

Cuando deja de ser un problema técnico y pasa a ser operativo

Aquí está una de las claves. El daño no se queda en base de datos.

Cuando una lógica de triggers se retroalimenta, el impacto se traduce enseguida en:

• bloqueos,
• esperas,
• lentitud,
• procesos que se pisan entre sí,
• herramientas que dejan de responder,
• y usuarios que solo perciben que «todo va raro».

Ese es uno de los peores escenarios en sistemas: cuando el síntoma aparece lejos de la causa. El usuario ve lentitud. El equipo funcional ve comportamientos inconsistentes. El soporte percibe que algo se degrada. Y por debajo, lo que está ocurriendo es una cadena automática que nadie modeló del todo bien.

El problema de fondo no son los triggers, es perder el mapa general

Igual que pasa con las integraciones o con la autoridad del dato, el problema real no suele estar en una sola pieza. Está en perder la visión del conjunto.

Con los triggers eso pasa mucho porque funcionan, se quedan, resuelven cosas y dejan de cuestionarse. Hasta que un día descubres que una parte importante de la lógica de negocio ya no está en la aplicación, ni en el proceso funcional, ni en la documentación. Está repartida en disparadores acumulados durante años.

Y cuando eso ocurre, cada cambio nuevo se vuelve más peligroso.

La conclusión es simple: potencia sí, pero con límites

Los triggers no son malos por definición. Pueden ser útiles, necesarios y muy potentes. Pero necesitan diseño, filtros claros y una revisión constante de su impacto.

Si no acotas bien:

• qué evento los dispara,
• en qué condiciones deben ejecutarse,
• qué datos modifican,
• y hasta dónde puede llegar su efecto,

acabas construyendo una cadena de automatismos difícil de seguir, difícil de mantener y muy peligrosa cuando falla.

A veces ocurre por prisas. A veces por resolver una urgencia. A veces porque cada decisión local parecía correcta. Pero los sistemas no suelen romperse por una única decisión aislada. Se rompen cuando nadie conserva ya el mapa general.

Y en ese punto, el trigger deja de ser ayuda y se convierte en riesgo.

Espero que os sea útil, suscribiros para que os lleguen avisos de la próxima entrada y no dudéis en comentar o mandar un mensaje con cualquier consulta, aportación o inquietud que tengáis…

… y si algo sale mal… La Culpa de Sistemas 😉