database - Pros y contras de desencadenantes frente a procedimientos almacenados para la desnormalización
sql-server-2008 stored-procedures (3)
Cuando se trata de desnormalizar datos en una base de datos transaccional para el rendimiento, hay (al menos) tres enfoques diferentes:
Enviar actualizaciones a través de procedimientos almacenados que actualizan tanto los datos transaccionales normalizados como los datos de informes / análisis desnormalizados;
Implementar desencadenantes en las tablas transaccionales que actualizan las tablas secundarias; esta es casi siempre la ruta que se toma cuando se mantienen historias;
Aplazar el procesamiento a un proceso por lotes nocturno, posiblemente haciendo un ETL en un almacén de datos / almacén.
Supongamos a los fines de esta pregunta que la opción n. ° 3 no es viable, porque el dominio requiere que los datos desnormalizados sean consistentes con los datos normalizados en todo momento. Los agregados jerárquicos, que trato bastante frecuentemente, son un ejemplo de esto.
He usado los dos primeros enfoques bastante y últimamente me he inclinado por el enfoque basado en disparadores, pero me pregunto si hay algún "truco" que no haya descubierto todavía, y pensé que valdría la pena hacer esta pregunta, así tendré algunas ideas para tener en cuenta al tomar decisiones a largo plazo en el futuro.
Entonces, en su experiencia, ¿cuáles son los pros y los contras de cualquiera de las herramientas para el propósito específico de mantener datos desnormalizados en tiempo real? ¿En qué situaciones elegirías una sobre la otra y por qué?
(PD Por favor, ninguna respuesta como "desencadenantes son demasiado complicados" o "todas las actualizaciones siempre deben ir a través de un proceso almacenado"; hágalo apropiado al contexto de la pregunta).
Depende de los requisitos de su negocio y de cómo se usa su base de datos. Por ejemplo, supongamos que hay muchas aplicaciones y muchas importaciones que afectan la tabla (tenemos cientos de cosas que pueden afectar nuestras tablas). Supongamos también que ocasionalmente existe la necesidad de escribir consultas que se ejecutan desde SSMS (sí, incluso en prod) para hacer cosas como actualizar todos los precios en un 10%. Si hace este tipo de cosas, entonces un proceso almacenado no es práctico, nunca tendrá todas las formas posibles de afectar la base de datos cubierta.
Si este cambio de datos es necesario para la integridad de los datos o si muchas aplicaciones o procesos (importaciones, trabajos de SQL Server, etc.) pueden afectar los datos, entonces deben pertenecer al desencadenador.
Si el cambio de datos es necesario solo algunas veces o usted tiene el control total de cómo se cambian los datos de una sola aplicación, entonces un proceso almacenado está bien.
Los desencadenadores son útiles cuando hay varias rutas de actualización en una tabla.
Usamos procesos almacenados y tenemos al menos 4 rutas (Agregar, Actualizar, Desactivar, Copiar)
Es más fácil trabajar con los datos que acabamos de insertar / actualizar en un desencadenante, sin importar qué acción hagamos o cuántas filas afectemos.
Un proceso almacenado funciona solo para una ruta de actualización única: a menos que quiera repetir el código ...
Ahora, TRY / CATCH en desencadenadores significa un manejo de errores correcto y predecible: los desencadenadores en SQL Server 2000 y anteriores provocaron abortos de lotes en error / retrotracción, que no es ideal (¡por decir lo menos!). Entonces, los disparadores son más confiables ahora de todos modos.
Los desencadenantes son efectos secundarios automáticos y es casi seguro que te morderán cuando quieres hacer algo y no pueden hacerlo debido a los efectos secundarios de los desencadenantes. Principalmente cosas como hacer que su sistema participe en alguna Transacción XA con otros sistemas externos. Los disparadores lo hacen IMPOSIBLE. También es la lógica del efecto secundario que SÓLO se puede activar haciendo el activador de activación de nuevo. Si desea recrear datos en el Almacén, no puede simplemente ejecutar algún procedimiento y volver a crearlo, debe ejecutar todas las actividades que activarán los Disparadores, esto es una pesadilla. INSERTS, UPDATES y DELETES deben ser idempotentes y ortogonales. Los disparadores complican innecesariamente los flujos de trabajo, incluso si cree que los están simplificando, no lo son.