Errores comunes en Bases de Datos: Lógica de negocios en Triggers

Imagen de: Picasa Web Albums

Con este artículo se realiza el lanzamiento de la nueva serie de "Errores comunes en Base de Datos", dedicada a describir los anti patrones de mayor referencia exclusivamente en desarrollo de base de datos y Programación en Structured Query Language (SQL).

En esta primera entrega se presenta el anti patrón de "Lógica de Negocio incluida en Desencadenadores", también conocido como Triggers, el cual se presenta cuando se utilizan los Triggers para la ejecución de cambios en ciertos datos desencadenadas por inserciones o actualizaciones de otros datos.

Al igual que otros anti patrones, no existe una posición unánime en la comunidad y los bandos que están a favor o en contra presentan cada uno las ventajas y desventajas de usarlos.

A continuación se describe el Anti Patrón de Lógica de Negocio en Descencadenadores:

Descripción del Anti Patrón de Lógica de Negocio

El anti patrón se presenta cuando se utilizan descencadenadores (Triggers) para representar lógica y reglas de negocio de muy alto nivel, como por ejemplo:

• Realizar la inserción de una transacción de tipo "Entrada de Inventario" actualizar vía Triggers el valor del inventario (Stock) asociado al producto, registro contable y demás información.

• Al realizar la inserción de un registro en una tabla que representa facturas, realizar la inserción vía Trigger de un registro de ingreso en la tabla que representa las transacciones de cuentas por cobrar.

• Al realizar una transacción de inserción de una tabla, realizar vía Triggers la llamada a un programa encargado de enviar emails.

• Al realizar una inserción registrar vía Trigger un registro en la tabla de auditoría del aplicativo, que indica usuario de aplicativo que realizó la modificación y su fecha.

Problemas ocasionados por el Anti Patrón

• Podrían los limites de implementación en cuanto a número de Triggers y capacidad para anidar transacciones.

• Los Triggers se ejecutan de forma no visible para aplicaciones cliente y no pueden ser rastreados por código de debugging. Por ende, el debugging tiende a ser más complejo y producir frustración.

• Es difícil seguir la lógica porque puede desencadenarse antes o después que ocurra la inserción o actualización en la base de datos.

• Son fáciles de olvidar, en especial cuando no se tienen procedimientos de documentación, por lo que futuros desarrolladores quizás ni siquiera conocerán su existencia.

• Tienden a escribirse asumiendo que la inserción es de un sólo registro (cuando se inserta más de un registro pueden existir errores).

Soluciones / Alternativas

Entre las alternativas está la implementación de esta lógica de negocio en Procedimientos Almacenados (Stored Procedures) que son más visibles para la aplicación, más fáciles de mantener y encontrar errores. Tanto la primera instrucción de inserción como la desencadenada (incluida originalmente en el Trigger) serán ejecutadas por un Procedimiento (Procedure) invocado desde la aplicación.

Otra alternativa es incluir está lógica en la capa de lógica de negocios y no en la capa de acceso a datos, por ejemplo se escribirá un código que realicé la inserción del primer registro y luego otra instrucción (desde la capa de aplicación) en el segundo registro (originalmente en el Trigger), ambos tendrán un Procedimiento (Procedure) asociado.

No existe una posición unánime en la comunidad sobre la conveniencia de usar Triggers o no y sobre que alternativas, por lo que el tema es fuente de polémica.

¿Y Que opina usted?

¿Que opina usted de incluir lógica de negocio en desencadenadores?, ¿Se ha encontrado esta práctica alguna vez?, ¿Como solucionó el problema?, ¿Que alternativas consideraría?.

Le invitamos a participar en el foro de discusión del blog de “La Oficina de Proyectos de Informática” (http://www.pmoinformatica.com) y a suscribirse al blog por los distintos canales, incluyendo lista de correo electrónico, al Twitter @PMOInformatica, a nuestra página de Facebook o al feed RSS.

<< Artículo anterior: Base de datos como comunicador de Procesos

Artículos de la serie "Errores comunes en Bases de Datos"

¿Quiere saber más sobre errores comunes de programación, le invitamos a revisar otros artículos de esta serie en el blog.

>> Errores comunes en el desarrollo de Bases de datos: Tercera Parte

>> Errores comunes en el desarrollo de Bases de datos: Segunda Parte
>> Errores comunes en el desarrollo de Bases de datos

Fuentes de referencia

c2.com. SQL Antipatterns

Jemerov, D. Writing Unmaintainable SQL. c2.com

Swart, M. Enforcing Business Rules Vs. Avoiding Triggers: Which Is Better?

Pinal, D. SQL SERVER – Disadvantages (Problems) of Triggers. SQLAuthority

¿Interesado en libros sobre desarrollo de bases de datos?

Transact SQL-DML Funciones y Bases  de datos Autor: Rocío Navarro Lacoba >> España (amazon.es) >> Latinoamérica (amazon.com)	Código Limpio Autor: Robert C. Martin >> España (amazon.es) >> Latinoamérica (amazon.com)	Métodos ágiles y Scrum Autor: Alonso Alvarez García y otros >> España (amazon.es) >> Latinoamérica (amazon.com)	Beginning Database Design Autor: Clare Churcher >> España (amazon.es) >> Latinoamérica (amazon.com)

Novedades Amazon

¿Interesado en otros productos amazon sobre Gestión de Proyectos y Desarrollo de Software?.

>> Sección de Productos Amazon

Otros artículos en “La Oficina de Proyectos de Informática”

Gestión de desarrollo de software

>> 5 Herramientas para la automatización de pruebas de software

>>10 actividades críticas a incluir en todo plan de desarrollo de un software

>> Los pasos para resolver incidentes en el período de estabilización de un desarrollo de software

>> Ambientes de pruebas integrales de software: Buenas prácticas

>> Ambientes de desarrollo de software: Buenas prácticas

>> Algunas prácticas de desarrollo de aplicaciones web para asegurar calidad, mantenibilidad, escalabilidad y seguridad

>> Acciones preventivas para evitar retraso y retrabajo en proyectos de tecnología de información (TI)

>> Las preguntas que debe hacer al encargarse de un proyecto de Tecnología de Información (TI) en ejecución