Triggers en SQL: automatizar acciones en la base de datos

Un trigger, que en español se traduce como disparador, es un fragmento de código almacenado en la base de datos que esta ejecuta de forma automática cuando ocurre un determinado evento en una tabla, siendo ese evento siempre un cambio en los datos, ya sea una inserción de una nueva fila, una modificación de una fila existente o un borrado de una fila. La característica que define y distingue a un trigger de otras formas de poner lógica en la base de datos es precisamente su ejecución automática, ya que a diferencia de un procedimiento almacenado, que es un bloque de código que alguien tiene que llamar explícitamente para que se ejecute, el trigger se dispara por sí solo cuando se produce el evento que lo activa, sin que la aplicación ni el usuario tengan que hacer nada ni acordarse de invocarlo. Al crear un trigger se especifican dos aspectos fundamentales. El primero es el momento en que actúa, que puede ser antes o después del cambio: un trigger que actúa antes se ejecuta justo antes de que el dato se guarde, lo que le permite revisar o modificar el dato entrante o incluso rechazar el cambio, mientras que un trigger que actúa después se ejecuta una vez que el cambio ya se ha realizado, lo que le permite reaccionar a él, por ejemplo registrando lo ocurrido o actualizando otra tabla. El segundo aspecto es el evento ante el que se dispara, es decir, si se activa ante una inserción, una modificación o un borrado, y sobre qué tabla. La combinación del momento, antes o después, y del evento, inserción, modificación o borrado, cubre la mayoría de los casos de uso de los triggers. Los triggers se utilizan principalmente para tres finalidades: la auditoría, registrando automáticamente quién cambió qué y cuándo; las validaciones y reglas de negocio, comprobando o corrigiendo los datos antes de guardarlos o impidiendo cambios que violen una regla; y el mantenimiento de datos derivados, actualizando automáticamente totales, contadores o campos calculados. Su gran ventaja es que la lógica reside en la propia base de datos, por lo que se cumple siempre, con independencia de qué aplicación o persona realice el cambio, aunque esta misma automatización invisible obliga a usarlos con criterio.

Un trigger se dispara cuando ocurre en la tabla a la que está asociado el evento que lo activa, que siempre es un cambio en los datos, y en el momento que se haya definido para él, que puede ser antes o después de que ese cambio se produzca. Los eventos que pueden disparar un trigger son los tres tipos de operaciones que modifican los datos de una tabla: la inserción, que ocurre cuando se añade una nueva fila; la modificación, que ocurre cuando se actualiza una fila existente; y el borrado, que ocurre cuando se elimina una fila. Al crear un trigger se especifica ante cuál o cuáles de estos eventos debe activarse, de modo que un trigger puede estar diseñado para dispararse, por ejemplo, solo ante las inserciones, o ante las modificaciones y los borrados, según lo que se necesite. Además del tipo de evento, se define el momento en que el trigger actúa en relación con el cambio, que es uno de los aspectos más importantes de los triggers. El momento puede ser antes del cambio o después del cambio. Un trigger que actúa antes del cambio se ejecuta justo antes de que la modificación de los datos se lleve a cabo, lo que le da la capacidad de intervenir sobre el dato que se va a guardar, ya sea para revisarlo, para modificarlo, por ejemplo normalizando un texto o asignando un valor por defecto, o para rechazar el cambio si este viola alguna regla, impidiendo así que se guarde. Un trigger que actúa después del cambio se ejecuta una vez que la modificación ya se ha realizado, lo que le permite reaccionar a un hecho ya consumado, por ejemplo registrando en una tabla de histórico lo que ha ocurrido, para la auditoría, o actualizando datos derivados en otras tablas, como totales o contadores, en función del cambio realizado. La regla mental para elegir el momento es sencilla: si se quiere influir en el dato que se va a guardar, se usa un trigger que actúe antes, mientras que si se quiere hacer algo como consecuencia de un cambio ya realizado, se usa uno que actúe después. Es importante tener presente que el trigger se ejecuta dentro de la misma transacción que provoca el cambio que lo dispara, lo que significa que forma parte de esa operación y que, si el trigger falla, puede provocar que toda la transacción se revierta, deshaciendo también el cambio original.

Los triggers se usan principalmente para tres finalidades en las que resulta especialmente valioso que cierto código se ejecute de forma automática ante los cambios en los datos: la auditoría, las validaciones y reglas de negocio, y el mantenimiento de datos derivados. La primera finalidad, y una de las más habituales y recomendables, es la auditoría, que consiste en registrar automáticamente quién ha cambiado qué dato y cuándo. Mediante un trigger que se dispara después de cada cambio en una tabla, se puede escribir de forma automática una entrada en una tabla de histórico o de auditoría que deje constancia de la modificación realizada, de modo que quede un registro completo de todos los cambios sin que la aplicación tenga que ocuparse de ello. La segunda finalidad son las validaciones y las reglas de negocio, que consisten en comprobar o corregir los datos antes de que se guarden, o en impedir cambios que violen alguna regla. Mediante un trigger que actúa antes del cambio, se puede revisar el dato entrante para verificar que cumple ciertas condiciones, corregirlo si es necesario, por ejemplo normalizándolo o completándolo, o rechazar directamente el cambio si incumple una regla, garantizando así la integridad de los datos según las reglas del negocio. La tercera finalidad es el mantenimiento de datos derivados, que consiste en actualizar automáticamente valores que dependen de otros datos, como totales, contadores o campos calculados. Mediante un trigger que se dispara tras un cambio, se puede recalcular y actualizar un total en otra tabla, incrementar o decrementar un contador, o mantener al día un campo que se calcula a partir de otros, de modo que estos datos derivados siempre reflejen el estado actual sin necesidad de recalcularlos manualmente. La gran ventaja común a estos tres usos es que la lógica reside en la propia base de datos y, por tanto, se ejecuta siempre, con independencia de qué aplicación o persona realice el cambio. Esto es especialmente importante para la auditoría y para las reglas críticas de integridad, ya que garantiza que queden registrados todos los cambios y que se cumplan todas las reglas, venga el cambio de donde venga, ya sea de la aplicación principal, de un script de mantenimiento, de otra aplicación o de un administrador que teclea instrucciones directamente, sin que nadie pueda saltarse la regla por olvido. Esta garantía de cumplimiento incondicional es lo que hace de los triggers una herramienta idónea para aquello que nunca debe fallar.

Los triggers, las vistas y los procedimientos almacenados son tres formas distintas de poner lógica o de organizar el acceso a los datos dentro de la base de datos, y se diferencian fundamentalmente en cómo se activan y para qué sirven cada uno. Las vistas son esencialmente consultas guardadas, es decir, consultas a las que se les da un nombre y se almacenan en la base de datos para poder usarlas como si fueran una tabla. Su finalidad es facilitar la lectura de los datos, presentando una determinada combinación o selección de datos de una forma cómoda y reutilizable, de modo que en lugar de escribir repetidamente una consulta compleja, se consulta la vista. Las vistas, por tanto, están orientadas a leer datos y no se ejecutan por sí solas, sino que se consultan cuando se necesitan. Los procedimientos almacenados son bloques de código que se guardan en la base de datos y que pueden realizar operaciones más complejas, incluyendo varias instrucciones, lógica y modificaciones de datos. Su característica es que hay que llamarlos explícitamente para que se ejecuten, es decir, alguien, ya sea la aplicación o un usuario, debe invocar el procedimiento para que este haga su trabajo, ejecutándose a demanda cuando se le pide. Los triggers, en cambio, son código que se ejecuta de forma automática ante determinados eventos de cambio en las tablas, sin que nadie tenga que llamarlos. Esta es la diferencia clave con los procedimientos: mientras que un procedimiento se llama a demanda, un trigger se dispara solo cuando ocurre el evento que lo activa, ya sea una inserción, una modificación o un borrado. Resumiendo las diferencias, se puede decir que las vistas son consultas guardadas orientadas a leer datos, que se consultan cuando se necesitan; los procedimientos son bloques de código que se llaman a demanda para realizar operaciones; y los triggers son código que se ejecuta solo, automáticamente, como reacción a los cambios en los datos. Cada uno tiene su ámbito de uso adecuado: las vistas para simplificar y reutilizar consultas de lectura, los procedimientos para encapsular operaciones que se ejecutan cuando se necesitan, y los triggers para automatizar reacciones a los cambios que deben ocurrir siempre, como la auditoría o ciertas reglas. Conocer estas tres piezas y sus diferencias permite elegir la más adecuada para cada necesidad, y a menudo se combinan en el diseño de una base de datos, aunque conviene recordar que los triggers, por su naturaleza automática e invisible, requieren un uso especialmente cuidadoso.

Hay que usar los triggers con cuidado porque la misma cualidad que los hace potentes, que es su ejecución automática e invisible, es también la que puede generar problemas de diagnóstico, de rendimiento y de complejidad si se abusa de ellos o se usan de forma inadecuada. El primer motivo de cuidado es lo que se puede llamar la magia invisible de los triggers. Como los triggers actúan por su cuenta cuando ocurre un cambio, sin aparecer en el código de la aplicación, un simple cambio en una tabla puede desencadenar efectos, como modificaciones en otras tablas o el rechazo de una operación, que no tienen ninguna explicación visible en el código de la aplicación. Esto da lugar al problema de diagnóstico más frustrante asociado a los triggers, que se resume en la pregunta de por qué se ha modificado un dato si nadie escribió código para ello, cuya respuesta suele estar en un trigger cuya existencia se desconocía. Esta invisibilidad dificulta enormemente la depuración y la comprensión del comportamiento del sistema. El segundo motivo de cuidado son los encadenamientos, ya que un trigger puede modificar otra tabla que a su vez tiene su propio trigger, que se dispara y modifica otra, creando cadenas de efectos difíciles de seguir y, en el peor de los casos, bucles que se retroalimentan. El tercer motivo es el rendimiento, ya que los triggers se ejecutan en cada uno de los cambios sobre la tabla a la que están asociados, de modo que un trigger que realice operaciones pesadas ralentizará todas las operaciones de inserción, modificación o borrado sobre esa tabla. El cuarto motivo es el riesgo de esconder lógica de negocio, ya que meter mucha lógica en los triggers la dispersa por la base de datos y la oculta, dificultando entender cómo funciona el sistema en su conjunto. Por todas estas razones, la recomendación es usar los triggers con moderación y visibilidad. Esto implica reservarlos para aquello que realmente se beneficia de ejecutarse siempre y de forma automática, como la auditoría y las reglas críticas de integridad; documentarlos adecuadamente para que el equipo sepa que existen y qué hacen; mantenerlos simples, de modo que hagan poco y de forma clara; y evitar los encadenamientos y la lógica de negocio compleja escondida en ellos. Además, conviene recordar que los triggers se ejecutan dentro de la transacción que los dispara, por lo que un fallo en un trigger puede provocar que toda la transacción se revierta. Usados con esta disciplina, los triggers son una herramienta excelente, pero usados como un cajón de sastre para toda clase de lógica escondida se convierten en una fuente de problemas.

Sí, un trigger puede provocar que se deshaga la operación que lo disparó, porque el trigger se ejecuta dentro de la misma transacción que provoca el cambio, y si el trigger falla o rechaza el cambio, puede hacer que toda la transacción se revierta, deshaciendo tanto el trabajo del trigger como el cambio original que lo activó. Para entender esto hay que recordar el concepto de transacción, que es una unidad de trabajo que agrupa una o varias operaciones y que se caracteriza por ser atómica, es decir, o se completa entera o no se hace nada, de modo que si algo falla dentro de la transacción, todo lo que se había hecho en ella se deshace, en lo que se conoce como reversión. Cuando un cambio en una tabla dispara un trigger, ese trigger no se ejecuta como algo separado, sino que forma parte de la misma transacción que el cambio que lo activó. Esto tiene una consecuencia importante: el destino del trigger y el del cambio están ligados. Si el trigger se ejecuta correctamente, la transacción puede continuar y confirmarse con normalidad. Pero si el trigger falla, por ejemplo porque encuentra un error o porque detecta que el cambio viola una regla y decide rechazarlo, ese fallo se propaga a la transacción, que se revierte por completo, deshaciendo no solo lo que hubiera hecho el trigger sino también el cambio original que lo disparó. Esta característica es en realidad muy útil y es la base de uno de los usos de los triggers, que es la validación mediante triggers que actúan antes del cambio. Un trigger de validación puede comprobar si el dato que se va a guardar cumple las reglas de negocio y, si no las cumple, provocar un error que haga que se rechace el cambio y se revierta la transacción, impidiendo así que se guarde un dato que viola las reglas. De este modo, el trigger actúa como un guardián que garantiza la integridad de los datos, con la certeza de que un cambio incorrecto no se llevará a cabo. Sin embargo, esta misma característica también forma parte de los aspectos que hay que tener en cuenta al usar triggers, ya que un trigger mal diseñado que falle de forma inesperada puede provocar que se deshagan operaciones legítimas, causando problemas difíciles de diagnosticar precisamente por la naturaleza invisible de los triggers. Por ello, al diseñar triggers, especialmente los de validación, hay que tener muy claro en qué casos harán que se rechace o se revierta una operación, para que su comportamiento sea el deseado y no cause reversiones no previstas.