Usare i trigger qui è solo un problema.
Inoltre, la scelta di utilizzare lo scheduler probabilmente non è l'idea migliore poiché i lavori pianificati possono visualizzare solo i dati impegnati. Quindi o stai impegnandoti nel trigger che getta la logica della transazione fuori dalla finestra o le modifiche alle tabelle vengono ritardate fino alla fine della transazione.
Dovresti:
-
Utilizzare le procedure. La risposta più semplice. Quando hai più applicazioni, non dovrebbero eseguire direttamente la logica DML/business, dovrebbero sempre farlo con le procedure in modo che eseguano tutte lo stesso codice. Vieta DML diretto con sovvenzioni o visualizzazioni. Potrebbe essere necessario forzare l'uso delle procedure tramite
INSTEAD OFattiva sulle viste (considera questo solo se non puoi modificare l'applicazione). -
Probabilmente anche meglio delle procedure nel tuo caso:usa uno schema che non contenga dati duplicati. Non vuoi archiviare dati ridondanti:questo rende lo sviluppo delle applicazioni più complesso del necessario. In termini di prestazioni, risorse ed energia, il modo migliore per risolvere un problema è quando ti rendi conto che il compito non è necessario.
Dalla descrizione del tuo modello, ecco le colonne che potresti rimuovere:
- task.duration_in_days
- data.fine_attività
- task.needs_recomputation
- sottoattività.data_inizio
- subtask.end_date
Iltaskla tabella conterrebbe solo la data di inizio e ogni sottoattività memorizzerebbe solo la sua durata. Quando hai bisogno delle informazioni aggregate, usa i join. Puoi utilizzare le visualizzazioni per consentire alle applicazioni di accedere ai dati in modo trasparente. -
Utilizzare una soluzione alternativa con trigger di mutazione che utilizza le variabili del pacchetto per identificare le righe modificate con
BEFOREeAFTERtrigger di istruzione. Ovviamente ciò comporterà molto codice che sarà difficile da codificare, testare e mantenere, quindi dovresti usare le opzioni (1) e (2) quando possibile.
