Déclencher des alternatives pour deux tables qui doivent se mettre à jour mutuellement

Utiliser des déclencheurs ici, c'est juste demander des ennuis.

De plus, le choix d'utiliser le planificateur n'est probablement pas la meilleure idée puisque les tâches planifiées ne peuvent voir que les données validées. Donc, soit vous vous engagez dans le déclencheur qui rejette la logique de transaction hors de la fenêtre, soit les modifications apportées aux tables sont retardées jusqu'à la fin de la transaction.

Vous devez soit :

1. Utiliser des procédures. La réponse la plus simple. Lorsque vous avez plusieurs applications, elles ne doivent pas exécuter directement la logique DML/business, elles doivent toujours le faire avec des procédures afin qu'elles exécutent toutes le même code. Interdire le DML direct avec attributions ou vues. Vous devrez peut-être forcer l'utilisation de procédures via INSTEAD OF déclencheurs sur les vues (considérez ceci uniquement si vous ne pouvez pas modifier l'application).

2. Probablement encore mieux que les procédures dans votre cas :utilisez un schéma qui ne contient pas de données en double. Vous ne souhaitez pas stocker de données redondantes :cela rend le développement d'applications plus complexe que nécessaire. En termes de performances, de ressources et d'énergie, la meilleure façon de résoudre un problème est de réaliser que la tâche est inutile.

   À partir de la description de votre modèle, voici les colonnes que vous pourriez supprimer :

   • task.duration_in_days
   • task.end_date
   • task.needs_recomputation
   • subtask.start_date
   • subtask.end_date

   
   La task table ne contiendrait que la date de début et chaque sous-tâche ne stockerait que sa durée. Lorsque vous avez besoin d'informations agrégées, utilisez des jointures. Vous pouvez utiliser des vues pour permettre aux applications d'accéder aux données de manière transparente.

3. Utilisez une solution de contournement du déclencheur mutant qui utilise des variables de package pour identifier les lignes modifiées avec BEFORE et AFTER déclencheurs d'instructions. Évidemment, cela impliquera beaucoup de code qui sera difficile à coder, tester et maintenir, vous devez donc utiliser les options (1) et (2) chaque fois que possible.