¿Es sabio usar el disparador para actualizar otra tabla?

8

Tengo una Objecttabla que se completa desde un servicio integrado ( que puedo cambiar si es necesario ) desde otra base de datos. En ciertos puntos, necesitamos agregar manualmente publicaciones en otra tabla ObjectObjectGroup (ObjectId, ObjectGroupId)que es necesaria si Object.ObjectTypetiene un cierto valor entero. Dado que el servicio de integración no maneja ese tipo de actualización, estoy pensando en agregar un desencadenador a la tabla Object que en pseudocódigo sería el siguiente:

if Object.ObjectType = 10
    begin
        if Object.ObjectNumber like '<string pattern>'
        begin
            insert into ObjectObjectGroup values...
        end
    end

¿Es sabia esta configuración, o hay una mejor manera en términos de rendimiento?

sql-server trigger Benny Skogberg
fuente

Respuestas:

9

Sobre todo copiar / pegar mi respuesta de esta pregunta en stackoverflow

Los disparadores pueden ser muy atractivos, cuando comienzas a usarlos parecen una bala mágica para todo tipo de problemas. Pero hacen que sucedan cosas "mágicas", si no conoce la base de datos al revés, puede parecer que suceden cosas realmente extrañas (como inserciones en otras tablas, cambio de datos de entrada, etc.). Antes de implementar las cosas como desencadenante, consideraría seriamente aplicar el uso de una API alrededor del esquema (preferiblemente en la base de datos, pero fuera si no puede).

Algunas cosas que todavía usaría desencadenantes para

  • Realizar un seguimiento de los campos "date_created" y "date_last_edited"
  • Insertar "ID" (en Oracle, donde no hay campo de identificación automática)
  • Manteniendo el historial de cambios

Cosas para las que no querrías usar disparadores

  • reglas de negocio / lógica
  • todo lo que se conecta fuera de la base de datos (por ejemplo, una llamada de servicio web)
  • Control de acceso
  • Cualquier cosa que no sea transaccional (cualquier cosa que haga en el disparador DEBE poder revertirse con la transacción)
Matthew Watson
fuente
4

Si, es sabio. Ese es el propósito de un disparador en realidad, realizar las acciones necesarias después de una operación de inserción / actualización / eliminación en una tabla.

Debe tener en cuenta el hecho de que un disparador en MS SQL no manejará cada fila por separado, sino que manejará todas las filas de la transacción actual a la vez. Entonces, si una operación insertará 10 filas a la vez, deberá pensar en el código de su activador para tratar todas las filas a la vez.

Mariana
fuente
1
Mientras el servicio que está poblando la base de datos no esté haciendo todo lo que el hombre necesita y mientras no pueda cambiar el servicio (eso es lo que siento después de la descripción), y la pregunta está aquí en DBA.SE, no en programadores , Diré que un disparador bien documentado no debería ser ningún problema. Dijo que está haciendo algunas cosas manualmente, por lo que el cambio de código no podría estar involucrado por lo que entiendo ...
Marian
1
En este caso, puede ser la única opción viable, que no lo hace sabio. Lo mejor sería presionar al desarrollador de la aplicación y hacer que se inserte correctamente en ambas tablas.
Matthew Watson el
tos . Veo a dónde se dirige esto. Perdón por no estar claro en mi pregunta anterior. Tengo la posibilidad de cambiar el servicio de integración, incluso si no es "de mi propiedad". Por lo que puedo leer, es mejor cambiar el servicio de integración y solo usar disparadores para los servicios de auditoría / registro de historial.
Benny Skogberg
3

Los disparadores son una herramienta poderosa y, como cualquier otra herramienta, debes tener cuidado al usarlos.

  1. Cuando comete un error en un disparador, las cosas pueden salir DRÁSTICAMENTE mal y, a menos que esté ejecutando rastros, no se dará cuenta ...

  2. Cambian / insertan / eliminan 'mágicamente' datos que el usuario de la base de datos (la aplicación actual / cualquier aplicación futura / un desarrollador que realice una actualización única) no realizó / tuvo la intención.

El gran problema es que después de haber creado el desencadenante, no es obvio para otros desarrolladores / usuarios que un desencadenante está ahí y lo que hace.

Dicho esto, son una gran herramienta para mantener la integridad de sus datos y para una verdadera auditoría de los cambios.

Debe preguntarse si la lógica que desea poner en el gatillo se adapta mejor a la (s) aplicación (es) o dentro del DB, sopesando los riesgos en ambos lados (qué sucede si aparece una nueva aplicación y no hace cumplir esto ¿regla?)

Andrew Bickerton
fuente