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

41

Cuando originalmente estaba aprendiendo sobre SQL, siempre se me decía que solo usara activadores si realmente lo necesitaba y opta por usar procedimientos almacenados en su lugar si es posible.

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

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

    
pregunta John Mitchell 03.12.2011 - 07:23

7 respuestas

29

El Artículo de Wikipedia sobre los activadores de bases de datos presenta una buena descripción de qué son los activadores y cuándo usarlos en diferentes bases de datos.

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

El uso de desencadenantes es bastante válido cuando su uso está justificado. Por ejemplo, tienen un buen valor en la auditoría (mantener el 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 cambien los datos y justo después de que se cambien los datos. Esto permite:

  • Auditoría como se mencionó anteriormente
  • La validación y la verificación de la seguridad del negocio, si así lo desea. Debido a este tipo de control, puede realizar tareas como el formato de columnas antes y después de las inserciones en la base de datos.
  

Siempre se me dijo, solo use desencadenantes si realmente lo necesita y opte por usar procedimientos almacenados en su lugar si es posible.

Pueden ser algunas de las razones de esto:

  1. Algunas funciones que los activadores solían hacer en los viejos tiempos ahora se pueden realizar de otras formas, como actualizar los totales y el cálculo automático en una columna.
  2. No ve dónde se invoca el activador 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 en la (s) mesa (s).
  3. Si usa varios controles de base de datos como CHECK, RI, Triggers en varias tablas, el flujo detallado de su transacción se vuelve complejo de entender y mantener. Tendrá que saber exactamente qué sucede cuando. Una vez más, necesitarás una buena documentación para esto.

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

  • Un procedimiento almacenado sin disparador es como un programa que debe invocarse explícitamente desde el código o desde un programador o desde un trabajo por lotes, etc. para realizar su trabajo, mientras que un disparador es un tipo especial de procedimiento almacenado que los incendios se producen como respuesta de un evento en lugar de ser ejecutados 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: INSTEAD OF, For y AFTER)
  • Los procedimientos almacenados sin disparador pueden hacer referencia a cualquier tipo de objeto; sin embargo, para hacer referencia a una vista, debe usar los activadores INSTEAD OF.
  • En SQLServer, puede tener cualquier número en procedimientos almacenados no activados, pero solo 1 activador INSTEAD OF por tabla.
respondido por el NoChance 03.12.2011 - 10:22
8

Los disparadores son un requisito para cualquier regla de integridad de datos compleja. Estos no se pueden imponer en ninguna parte excepto en la base de datos o tendrá problemas de integridad de datos.

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

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

Los disparadores a menudo son 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, úselo en lugar de un disparador.

Es fácil escribir malos desencadenantes 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 falla?

En el servidor SQL, los disparadores operan en un lote de registros. Con demasiada frecuencia, los desarrolladores creen que solo necesitan manejar un registro de inserciones, actualizaciones o eliminaciones. Ese no es el único tipo de cambios de datos que ocurren en una base de datos y todos los desencadenantes deben probarse en las condiciones de un cambio de registro y muchos cambios de registro. Olvidarse de realizar la segunda prueba puede llevar a desencadenantes extremadamente deficientes o a la pérdida de integridad de los datos.

    
respondido por el HLGEM 06.12.2011 - 22:46
2

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

Por ejemplo, recientemente trabajé en una base de datos que anteriormente existía como un sistema de oficina únicamente. Cuando se escribía una aplicación web para interactuar con ella, queríamos implementar un sistema de notificación (similar a stackexchange, por ejemplo), que se activaría mediante 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 dispararan un activador para crear la notificación para el frontend y decirle al usuario que su transacción había sido procesada por la oficina.

    
respondido por el Matt 24.02.2012 - 16:04
1

Los desencadenadores se pueden usar 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 declaración DML.

    
respondido por el DEEPAK JADGE 03.10.2012 - 07:11
1

Uso de activadores de base de datos

  1. Para controlar los valores de las columnas automáticamente.
  2. Para imponer restricciones de integridad complejas.
  3. Para hacer cumplir reglas de negocio complejas.
  4. Para personalizar autorizaciones de seguridad complejas.
  5. Para mantener tablas replicadas.
  6. Para auditar la modificación de datos.
respondido por el asha 10.03.2013 - 08:20
0

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

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

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

En su lugar, puede poner un disparador en la tabla para mantener la cola actualizada. Garantizado para no perderse nada. Una ubicación central. ¿Pena de rendimiento? En realidad, no porque el golpe de rellenar la cola no se puede evitar ya sea por disparador o externo.

En este escenario, diría que no usar un activador es una mala elección de diseño. Si luego desea usar un nuevo método para enviar datos (digamos que la cola no está funcionando) y la interfaz cambia, está protegido si usa el activador. Los desencadenantes suelen ser la mejor opción. No escuches a los fanáticos dogmáticos anti-disparo.

    
respondido por el Lord Tydus 03.12.2011 - 20:18
-6

Un disparador que envía un correo electrónico no es necesariamente una idea "estúpida". Lo que es estúpido es no anticipar la interrupción del correo electrónico en el diseño y manejarlo con elegancia sin pérdida de datos. La parte 'estúpida' de esto es realmente mala o inexistente en el manejo 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 disparador se puede mantener simple invocando un procedimiento / función almacenado que puede ser arbitrariamente complicado y bien puede ser reutilizable por múltiples disparadores u otros procedimientos almacenados. Es por eso que hay paquetes y bibliotecas.

La intolerancia es realmente paralizante.

    
respondido por el ALLEN MARSHALL 09.09.2016 - 21:08

Lea otras preguntas en las etiquetas