Usar disparadores aquí es solo buscar problemas.
Además, la elección de usar el programador probablemente no sea la mejor idea, ya que los trabajos programados solo pueden ver los datos confirmados. Entonces, o se está comprometiendo en el activador que arroja la lógica de la transacción por la ventana o los cambios en las tablas se retrasan hasta el final de la transacción.
Deberías:
-
Utilizar procedimientos. La respuesta más simple. Cuando tiene varias aplicaciones, no deben realizar la lógica DML/de negocios directamente, siempre deben hacerlo con procedimientos para que todas ejecuten el mismo código. Prohibir DML directo con subvenciones o vistas. Es posible que deba forzar el uso de procedimientos a través de
INSTEAD OFactiva en las vistas (considere esto solo si no puede modificar la aplicación). -
Probablemente incluso mejor que los procedimientos en su caso:use un esquema que no contenga datos duplicados. No desea almacenar datos redundantes:esto hace que el desarrollo de aplicaciones sea más complejo de lo necesario. En términos de rendimiento, recursos y energía, la mejor manera de resolver un problema es cuando te das cuenta de que la tarea es innecesaria.
De la descripción de su modelo, estas son las columnas que podría eliminar:
- tarea.duración_en_días
- tarea.fecha_de_finalización
- tarea.necesita_recomputación
- subtarea.start_date
- subtarea.end_date
Lataskla tabla contendría solo la fecha de inicio y cada subtarea solo almacenaría su duración. Cuando necesite la información agregada, use uniones. Puede usar vistas para permitir que las aplicaciones accedan a los datos de forma transparente. -
Utilice una solución alternativa del activador mutante que usa variables de paquete para identificar filas modificadas con
BEFOREyAFTERdisparadores de declaraciones. Obviamente, esto implicará una gran cantidad de código que será difícil de codificar, probar y mantener, por lo que debe usar las opciones (1) y (2) siempre que sea posible.
