Activadores SQL y cuándo o cuándo no usarlos.

Cuando estaba aprendiendo originalmente sobre SQL, siempre me dijeron que solo usara disparadores si realmente lo necesita y opte por usar procedimientos almacenados si es posible.

Ahora, desafortunadamente en ese momento (hace unos pocos años), no tenía tanta curiosidad y preocupación por los fundamentos como ahora, así que nunca pregunté por qué.

¿Cuál es la opinión de las comunidades en esto? ¿Es solo la preferencia personal de alguien, o deberían evitarse los desencadenantes (al igual que los cursores) a menos que haya una buena razón para ellos?

El artículo de Wikipedia sobre los desencadenantes de la base de datos presenta una buena visión general de qué son los desencadenantes y cuándo usarlos en diferentes bases de datos.

La siguiente discusión se basa únicamente en SQL Server.

El uso de disparadores es bastante válido cuando su uso está justificado. Por ejemplo, tienen un buen valor en la auditoría (mantenimiento del historial de datos) sin requerir un código de procedimiento explícito con cada comando CRUD en cada tabla.

Los disparadores le dan control justo antes de que se modifiquen los datos y justo después de que se modifiquen. Esto permite:

• Auditoría como se mencionó anteriormente
• Validación y comprobación de seguridad empresarial si así se desea. Debido a este tipo de control, puede realizar tareas como el formateo de columnas antes y después de las inserciones en la base de datos.

Siempre me dijeron, solo use disparadores si realmente lo necesita y opte por usar procedimientos almacenados si es posible.

Pueden ser algunas de las razones para esto:

1. Algunas funciones que los desencadenantes solían hacer en los viejos tiempos ahora se podían realizar de otras maneras, como la actualización de totales y el cálculo automático en una columna.
2. No puede ver dónde se invoca el desencadenante al examinar el código solo sin saber que existen. Usted ve su efecto cuando ve los cambios en los datos y a veces es desconcertante descubrir por qué ocurrió el cambio a menos que sepa que hay un disparador o más actuando sobre la (s) tabla (s).
3. Si utiliza varios controles de base de datos como CHECK, RI, Triggers en varias tablas, su flujo detallado de transacciones se vuelve complejo de entender y mantener. Necesitará saber exactamente qué sucede cuando. Nuevamente, necesitará una buena documentación para esto.

Algunas diferencias entre los desencadenantes y los procedimientos almacenados no desencadenantes son (entre otros):

• Un procedimiento almacenado no desencadenante es como un programa que debe invocarse explícitamente desde un código o desde un planificador o desde un trabajo por lotes, etc. para hacer su trabajo, mientras que un desencadenante es un tipo especial de procedimiento almacenado que se activa como un respuesta de un evento en lugar de ser ejecutado directamente por el usuario. El evento puede ser un cambio de datos en una columna de datos, por ejemplo.
• Los disparadores tienen tipos. Disparadores DDL y Disparadores DML (de tipos: EN LUGAR DE, Para y DESPUÉS)
• Los procedimientos almacenados sin disparador pueden hacer referencia a cualquier tipo de objeto, sin embargo, para hacer referencia a una vista, debe usar los disparadores INSTEAD OF.
• En SQLServer, puede tener cualquier número en procedimientos almacenados sin desencadenante, pero solo 1 desencadenante INSTEAD OF por tabla.

Los disparadores son un requisito para cualquier regla de integridad de datos compleja. No se pueden aplicar en ningún otro lugar, excepto en la base de datos, o tendrá problemas de integridad de datos.

También son el mejor lugar para auditar a menos que no desee capturar todos los cambios en la base de datos (que es el problema de auditar desde la aplicación).

Los desencadenantes pueden causar problemas de rendimiento si no se escriben con cuidado y no hay suficientes desarrolladores que tengan los conocimientos necesarios para escribirlos bien. Esto es parte de donde obtienen su mala reputación.

Los desencadenadores suelen ser más lentos que otros medios para mantener la integridad de los datos, por lo que si puede usar una restricción de verificación, utilícela en lugar de un desencadenante.

Es fácil escribir disparadores erróneos que hacen cosas estúpidas como intentar enviar correos electrónicos. ¿Realmente desea no poder cambiar los registros en la base de datos si el servidor de correo electrónico se cae?

En el servidor SQL, los disparadores operan en un lote de registros. Con demasiada frecuencia, los desarrolladores piensan que solo necesitan manejar inserciones, actualizaciones o eliminaciones de un registro. Ese no es el único tipo de cambio de datos que le sucede a una base de datos y todos los desencadenantes deben probarse bajo las condiciones de 1 cambio de registro y muchos cambios de registro. Olvidar hacer la segunda prueba puede provocar desencadenantes con un rendimiento extremadamente bajo o una pérdida de integridad de los datos.

Uso de desencadenantes de bases de datos

1. Para conducir valores de columna automáticamente.
2. Para imponer restricciones de integridad complejas.
3. Hacer cumplir reglas comerciales complejas.
4. Para personalizar autorizaciones de seguridad complejas.
5. Para mantener tablas replicadas.
6. Para auditar la modificación de datos.

Otro caso de uso que he encontrado personalmente es para bases de datos a las que accede más de un programa. Si desea implementar la funcionalidad pero no rediseñar todos los sistemas para ello, un disparador es una solución sensata.

Por ejemplo, recientemente trabajé en una base de datos que anteriormente había existido únicamente como un sistema de oficina. Cuando se escribió una aplicación web para interactuar con ella, queríamos implementar un sistema de notificación (similar a stackexchange, por ejemplo), que sería disparado por múltiples eventos, como el procesamiento de una transacción, etc. Pudimos implementar un activador para que las actualizaciones en el backend de la oficina activaran un activador para crear la notificación para la interfaz y decirle al usuario que su transacción había sido procesada por la oficina.

Los desencadenantes se pueden utilizar para imponer restricciones en la base de datos que no se pueden aplicar durante la creación del esquema de la base de datos y cualquier instrucción DML.

Digamos que necesita enviar datos a un sistema de terceros en tiempo casi real. Su tabla contiene 950 gigabytes de datos, por lo que es demasiado grande para simplemente enviar toda la tabla a la aplicación de terceros.

En su lugar, acumula cambios en una cola. Algún programa externo enviará periódicamente pequeños lotes de datos en cola.

El sistema tiene más de 2000 procedimientos almacenados. También sabe que existen toneladas de sql en el código fuente. Para garantizar que la cola se complete correctamente, deberá buscar en todos los procesos y códigos almacenados y esperar que no se pierda nada.

En su lugar, puede poner un activador en la tabla para mantener actualizada la cola. Garantizado para no perderse nada. Una ubicación central. ¿Penalización de rendimiento? En realidad no porque el éxito de llenar la cola no se pueda evitar ya sea por desencadenante o externo.

En este escenario, diría que no usar un disparador es una mala elección de diseño. Si más tarde desea utilizar un nuevo método para enviar datos (por ejemplo, la cola no funciona) y la interfaz cambia, estará protegido si utiliza el disparador. Los disparadores son a menudo la mejor opción. No escuches a los fanáticos dogmáticos anti-disparadores.

Un disparador que envía un correo electrónico no es necesariamente una idea "estúpida". Lo estúpido es no anticipar la interrupción del correo electrónico en el diseño y manejarlo con gracia sin pérdida de datos. La parte 'estúpida' de esto es realmente mala para el manejo inexistente de errores por parte de desarrolladores perezosos que sienten que son inmunes a cometer errores.

También ofrecería la observación de que un desencadenante puede mantenerse simple invocando un procedimiento / función almacenado que puede ser arbitrariamente complicado y bien puede ser reutilizable por múltiples desencadenantes u otros procedimientos almacenados. Por eso hay paquetes y bibliotecas.

La intolerancia es realmente paralizante.