¿Es sabio usar el disparador para actualizar otra tabla?

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?

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)

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.

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?)