A veces nos toca trabajar con proyectos donde el programador original usa disparadores de SQL en las tablas y desafortunadamente, solemos encontrar muy seguido  que estos no están escritos en la manera más eficiente. Me gustaría subrayar algunos errores comunes que hemos visto cuando se usan disparadores.

Asumir que es solo una fila

No puedo citar el número de veces que he tenido que ejecutar operaciones de datos a granel solo para verlas fallar o  generar resultados inesperados solo porque un disparador no pudo manejarlo. Esto no es más que, el desarrollador simplemente asume que solo se insertará, actualizará o borrará una fila a la vez. Esta es una muy mala suposición. A veces el desarrollador original debería poner una verificación como esta:

IF ((SELECT COUNT(*) FROM inserted) = 1)
>do the thing<

Lo que está bien pero me trae al siguiente punto…

 

Definir disparadores que solo deberían ejecutarse algunas veces.

Si es solo para insertar/actualizar un registro único ¿en realidad debe ser un disparador? ¿Por qué no ponerlo en un evento AfterUpdate de Access en el formulario o procedimiento almacenado? Los disparadores incurren en cierta sobrecarga y limitar a sólo la operación de una fila hace que se pierde el valor del disparador y un mejor enfoque para la gestión de la lógica. Créame, usted en realidad no desea un disparador que solo es aplicable algunas veces. El disparador siempre se disparará y para reglas de negocio que solo son aplicables en algunas circunstancias, considero que hay  mejores soluciones.

Usando cursores o procedimientos en los disparadores.

Déjenme hacerlo totalmente claro. SQL Server está optimizado para las operaciones basadas en conjuntos, y no de operaciones de procedimiento. La tentación de escribir T-SQL de la misma manera que escribimos VBA o C# o cualquier lenguaje de programación que utilice es grande. No lo haga, Lo que conoce acerca de su lenguaje favorito NO aplica a SQL. Usar cursores le permite escribir T-SQL un poco más de procedimiento pero es similar a clavar clavos con una llave. Eventualmente se enterará  de que los resultados no son bonitos. La clave sobre los disparadores en SQL Server es que están basado en sentencias, lo que significa que todas las filas que están siendo operadas se ven afectadas una vez. Es por esto que tenemos las tablas inserted y updated, y no un constructor de una sola fila. Otros RDBMS soportan disparadores basados en filas pero por alguna razón, Microsoft ha rechazado darle soporte a este tipo de construcción. En muchas ocasiones, no debería importar –usted desea que sus disparadores corran tan rápido como pueda lo que significa ser capaz de lidiar con  los inserts y deletes como lo que son- tablas para ser operadas como un conjunto. Muchas veces, es posible reescribir un disparador que solo maneja una fila en uno que trabaje con ilimitadas filas, eliminando el constructor IF. Eso es una gran ganancia en el rendimiento.

Pero y ¿qué tal si solo necesito a veces y no lo puede hacer en el cliente?

Existen numerosos casos donde tenemos que hacer cumplir las reglas de negocio y que no siempre son aplicables. La clave es definir un disparador en una vista en lugar de hacerlo en la tabla base. Puede crear un INSTEAD OF disparador sobre una vista y mostrarla al cliente. Ya que el disparador está relacionado con la vista, manipular la tabla base no hará que el disparador se ejecute, lo cual es bueno y malo

Un gran punto a favor en mi libro para definir disparadores en vistas es este-  siempre escribo mi definición de una vista de la siguiente manera:

CREATE VIEW dbo.vwMyView AS
— IMPORTANT: There is a trigger(s) defined on this view
— If the view is altered, check the trigger to ensure
— it is consistent with the new view definition
SELECT
aColumn,
otherColumn
FROM dbo.aTable;

Ahora me siento más seguro puesto que si tengo que volver a revisar la vista el año próximo o si alguien más viene y lo lee, ellos no van a quedar desagradablemente sorprendidos al enterarse  que hay disparadores acechando en las sombras. Trate hacer eso con el disparador en una tabla. No es tan sencillo documentar o descubrir especialmente porque no solemos  hacer ALTER TABLE y que este contenga toda la información como lo hace un ALTER VIEW. No es a prueba de balas pero mucho mejor solución que hacer un disparador directamente en la tabla.

Al final, use con moderación.
Una desafortunada consecuencia de crear disparadores es que cuestan más mantenimiento. Si hace un esquema que contenga muchos disparadores puede hacer que esta sea más frágil que una casa de naipes. En ocasiones es solo que las reglas de negocios es mejor aplicarlas en la aplicación o hacerlo menos a nivel de base de datos. Listo cierto, pueden ser sorprendente y simplificar su desarrollo. Solo sea cauteloso con los dobles filos.

 

Feliz elección.