Ni el SQL standard ni ninguno de los principales sistemas gestores de bases de datos soportan triggers ON COMMIT (es decir, triggers que se ejecutan cuando se hace un commit de una transacción). La única excepción qeu conozco (AFAIK) es Firebird

La verdad es que me pregunto el porqué. Yo los encuentro muy útiles, especialmente para comprobar que las modificaciones de datos durante la transacción no violan ninguna de las restricciones de integridad del modelo. Y no estoy pensando en reglas muy complejas, incluso para algunas restricciones de multiplicidad de asociaciones sería necesario disponer de este tipo de trigger, hacer comprobaciones durante la transacción no es suficiente (y además en ese caso tenemos el típico problema de las “mutating tables” por culpa de intentar leer datos de las tablas que estamos justamente modificando).

Dejadme que os ponga un pequeño ejemplo. Imaginad que tenemos que generar el esquema para este diagrama de clases UML

donde se indica que todos los estudiants tienen que estar matriculados como mínimo en un curso. ¿Cómo podemos controlar esta restricción en la base de datos? Una opción sería definir un trigger AFTER DELETE en la tabla EnrolledIn pero esto es solamente una solución parcial que comprueba que los estudiantes no se borran de cursos ya matriculados pero ¿qué pasa con los estudiantes nuevos? ¿Cómo comprobamos que se matriculan de algo? (aquí un trigger AFTER INSERT en Student no nos sirve, tenemos que hacer la comprobación al final de la transacción no justo después de crear el estudiante).

Por supuesto hay soluciones alternativas como controlar la restricción fuera de la base de datos, como parte del código de la aplicación pero para mí esta opción es pero ya que prefiero tener las restricciones tan centralizadas como sea posible (sinó cada vez que creamos una nueva aplicación o formulario tenemos que recordar de incluir allí la verificación de todas las restricciones que se pueden ver afectadas)

Además la ausencia de este tipo de trigger es todavía más estraña si se tiene en cuenta que diversos gestores de bases de datos (como Oracle) permiten definir primary, foreing, unique y check constraints como “deferred”. Cuando una constraint se define como deferred se comprueba al final de la transacción y no a continuación de cada modificación individual, es decir justamente el mismo concepto que el de nuestro trigger on commmit!

En todo caso, si os preguntábais el porqué el servicio de generación de bases de datos UMLtoDB ignora las restricciones de multiplicidad, ahora ya sabéis el porqué

Si te ha gustado esta entrada, puedes subscribirte a este Software Modeling blog y/o seguirme en twitter y/o a través de la lista de distribución del portal Y si realmente te ha gustado ayúdame a hacerlo llegar a otros utilizando los bookmarks que tienes a continuación: