DB2: Los triggers, haciendo el trabajo sucio

En esta ocasión voy a presentaros a los triggers. Estos son otra pata de las herramientas que tenemos en la base de datos para automatizar acciones a nivel de registro de la información.

La mejor explicación es que el trigger es nuestra herramienta para realizar acciones cuando sucede «algo» en la base de datos y de esta manera agregar controles sobre la aplicación GEINFOR ERP sin necesidad de tocar programación de la aplicación. Sigue leyendo y nos metemos en faena

Para ser pesado y repetitivo como siempre:

NINGUNA DE LAS ACCIONES QUE VOY A EXPLICAR TIENE SOPORTE POR PARTE DE GEINFOR. MUCHO OJO Y BAJO VUESTRA RESPONSABILIDAD

¿Cómo funcionan los triggers?

Un trigger es un «disparador» a nivel tabla de base de datos, esto quiere decir que cuando suceda el evento que hayamos programado, el trigger entrará en acción y eso sucederá registro a registro de la tabla. Si escribimos 3 veces en una tabla y hay un trigger sobre ella que se activa al escribir, se ejecutará 3 veces.

La explicación más larga la podéis consultar en la wikipedia aquí o preguntar a google, pero el concepto necesario es este.

¿Qué eventos activan los triggers?

Pues básicamente a nivel fila de tabla de la base de datos tenemos 3:

  • Insert: Al crear
  • Delete: Al borrar
  • Update: Al modificar

Para cada ejecución, podemos activarlos:

  • Before: Antes de la modificación en la base de datos
  • After: Despues de la modificación en la base de datos
  • Instead of: en el mismo momento de la modificación de la base de datos

Además de estas combinaciones, tenemos que en función de la combinatoria de las 3 y 3 opciones anteriores, tendremos acceso a la tabla con los valores «nuevos» y «viejos» de forma que podremos programar de forma similar a una Pocedure que debe realizar la base de datos. Toda la estructura completa de los trigger la tenéis en el siguiente link de IBM

Sacado de la página de IBM un pequeño cuadro resumen sería:

Granularity Activation time Triggering SQL operation Transition variables allowed1 Transition tables allowed1
FOR EACH ROW BEFORE DELETE OLD None
INSERT NEW None
UPDATE OLD, NEW None
AFTER DELETE OLD OLD_TABLE
INSERT NEW NEW_TABLE
UPDATE OLD, NEW OLD_TABLE, NEW_TABLE
INSTEAD OF DELETE OLD OLD_TABLE
INSERT NEW NEW_TABLE
UPDATE OLD, NEW OLD_TABLE, NEW_TABLE
FOR EACH STATEMENT AFTER DELETE None OLD_TABLE
INSERT None NEW_TABLE
UPDATE None OLD_TABLE, NEW_TABLE

Recomendaciones/normas de los Gremlins para los Triggers

  • Comienza todas las vistas por TR_
  • La siguiente parte del nombre utilizarla para que todas las relacionadas estén juntas. La mejor opción es utilizar el nombre de la tabla donde actuará
  • La última parte del nombre la utilizaremos para saber cuando actuará _CR (al crear), _BUP (antes de modificar), _AUP (después de modificar, _DEL(al eliminar)
  • Añade un comentario en la creación del Trigger. ¡Comenta tu código! no es un telegrama y no se cobra por palabras

Creando el primer trigger:

Para un ejemplo de trigger va a ser algo sencillito. En el lanzamiento de ordenes de Geinfor ERP, vamos a actualizar el lote de fabricación del almacén con la cantidad de la orden que acabamos de lanzar.

Este ejemplo resulta que si nuestra producción es siempre «trajes a medida» y por operativa de la empresa el lote de fabricación habitual es la última fabricación, nos ahorraremos que para cada orden el usuario tenga que ir código a código a modificar dicha información en el almacén

Vamos a crear 2 triggers para asegurarnos que la información está siempre actualizada. Por un lado cuando creamos la orden:

CREATE OR replace TRIGGER TR_ORDENES_DE_TRABAJO_CR AFTER INSERT ON ORDENES_DE_TRABAJO
REFERENCING NEW AS NEW NEW_TABLE AS TNEW FOR EACH ROW MODE DB2SQL

BEGIN ATOMIC
UPDATE ALMACEN_ARTICULOS
SET LOTEFABRICACION= NEW.CANTIDAD_PEDIDA + NEW.CANT_EN_DESVIACION
WHERE ARTICULO=NEW.CODIGO_ARTICULO AND ALMACEN=NEW.ALMACEN;

END;

Como se puede seguir en el codigo, el trigger se ejecutará después de insertar en la tabla (por aquello de asegurarnos que la orden está realmente lanzada) y actualizará la tabla de ALMACEN_ARTICULOS con la nueva cantidad

Por otro lado al modificar la orden:

CREATE OR replace TRIGGER TR_ORDENES_DE_TRABAJO_AUP after UPDATE ON ORDENES_DE_TRABAJO
REFERENCING NEW AS N OLD AS O
FOR EACH ROW

BEGIN
UPDATE ALMACEN_ARTICULOS
SET LOTEFABRICACION=N.CANTIDAD_PEDIDA+N.CANT_EN_DESVIACION
WHERE ARTICULO=N.CODIGO_ARTICULO AND ALMACEN=N.ALMACEN;

En este caso, de la misma forma, cuando se realiza un UPDATE en la tabla, DESPUÉS de que se haya escrito en ella, se realiza la actualización del valor de ALMACEN_ARTICULOS

Es un ejemplo muy sencillo pero que nos sirve para dos cosas:

  • Una introducción rápida y sencilla a los triggers
  • Ahorrar tiempo al usuario, evitando también el error humano

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 😉

Un comentario en “DB2: Los triggers, haciendo el trabajo sucio

Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.