C'è un problema nell'uso di ON DELETE CASCADE su chiavi esterne in un database SQL se ci sono più percorsi dalla chiave esterna di root all'anta. Il modo per aggirare questo sembra essere quello di sostituire ON DELETE CASCADE s con INSTEAD OF DELETE trigger.
Tuttavia diversi post di Overflow dello stack (ad es. qui , qui ) e qui suggeriscono di utilizzare i trigger solo come" l'ultima risorsa ". Perché?
Credo che non ci sia sfiducia nei trigger perché una volta creati non sono ben visualizzati in varie interfacce e non comunicano che vengono eseguiti in modi molto intuitivi.
Questo porta ad una sensazione di "magia" in cui le cose possono accadere nel tuo database che non ti aspetti e non vengono rese consapevoli. La cancellazione di più di quanto ti aspetti potrebbe essere l'effetto collaterale più spaventoso.
Come tante cose se vengono abusate possono essere orribili, ma sono molto potenti se usate bene.
Se avessi 3 desideri di rendere la mia vita più facile nell'IT, la parte superiore dell'elenco sarebbe quella di costringere gli sviluppatori a fare formazione sui DB. Vedo tanta ignoranza su vari RDBMS che fa paura.
I trigger non sono come alcuni potrebbero credere "nascosti" sono liberamente visibili e fanno come sono programmati. Né corrono dietro le quinte in modo nefasto. Corrono senza intralciare l'elaborazione principale - esattamente ciò che sono progettati per fare.
Ciò che è vero è che tendono ad essere l'ultimo posto in cui si pensa di cercare query di supporto, ecc. perché sono usate così raramente. Questa è solo la natura umana.
Se sei preoccupato che le righe vengano cancellate senza essere informate, ci sono molte opzioni a tua disposizione, ad es. output deleted.* oppure puoi semplicemente contrassegnare i record come cancellati invece di eliminarli completamente (a seconda dei limiti di spazio di archiviazione ovviamente).
Leggi altre domande sui tag sql sql-server tsql