Udløs alternativer for to tabeller, der gensidigt skal opdatere hinanden

At bruge triggere her er bare at bede om problemer.

Ydermere er valget af at bruge planlæggeren sandsynligvis ikke den bedste idé, da de planlagte job kun kan se forpligtede data. Så enten forpligter du dig i triggeren, som kaster transaktionslogikken ud af vinduet, eller også bliver ændringerne af tabellerne forsinket til slutningen af ​​transaktionen.

Du skal enten:

1. Brug procedurer. Det enkleste svar. Når du har flere applikationer, bør de ikke udføre DML/businees logik direkte, de skal altid gøre det med procedurer, så de alle kører den samme kode. Forbyd direkte DML med tilskud eller synspunkter. Du skal muligvis tvinge brugen af ​​procedurer gennem INSTEAD OF udløsere på visninger (overvej kun dette, hvis du ikke kan ændre applikationen).

2. Sandsynligvis endnu bedre end procedurer i dit tilfælde:brug et skema, der ikke indeholder duplikerede data. Du ønsker ikke at gemme overflødige data:Dette gør applikationsudvikling mere kompleks end nødvendigt. Med hensyn til ydeevne, ressourcer og energi er den bedste måde at løse et problem på, når du indser, at opgaven er unødvendig.

   Fra beskrivelsen af ​​din model er her de kolonner, du kan fjerne:

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

   
   task tabel ville kun indeholde startdatoen, og hver underopgave ville kun gemme dens varighed. Når du har brug for de samlede oplysninger, skal du bruge joinforbindelser. Du kan bruge visninger til at lade applikationerne få adgang til dataene gennemsigtigt.

3. Brug en løsning af muterende trigger der bruger pakkevariabler til at identificere modificerede rækker med BEFORE og AFTER statement triggere. Dette vil naturligvis involvere masser af kode, som vil være svære at kode, teste og vedligeholde, så du bør bruge mulighederne (1) og (2), når det er muligt i stedet for.