In genere sono diffidente nei confronti delle eliminazioni a cascata (e di altre azioni automatiche che potrebbero far cadere / danneggiare i dati), sia tramite trigger o ON <something> CASCADE. Tali strutture sono molto potenti, ma anche potenzialmente pericolose.
- Quindi, eliminare a cascata è una scelta corretta qui?
Farebbe sicuramente quello che stai cercando di fare: rimuovere i record correlati quando viene rimosso un record principale, senza che sia necessario implementare qualsiasi altra logica per garantire che i bambini vengano rimossi per primi, quindi rendendo il codice più conciso. Tutte le azioni saranno racchiuse in una transazione implicita, quindi se qualcosa blocca il bambino elimina l'intera operazione viene bloccata, mantenendo l'integrità referenziale con uno sforzo di codifica minimo o nullo.
Assicurati che il tuo uso di eliminazioni in cascata e altre azioni "dietro le quinte" siano ben documentati in modo che i futuri manutentori del sistema ne siano pienamente consapevoli.
- Quando il detele in cascata non deve essere usato?
Non dovrebbe essere usato se sei paranoico come me! Un punto chiave da considerare è gli altri sviluppatori che attualmente, o potrebbero in futuro, lavorano sul tuo codice / database (da qui il commento sopra sulla documentazione di eventuali comportamenti "nascosti").
È abbastanza comune nella mia esperienza per le persone inesperte usare DELETEquindi ri INSERT-aggiornare le righe, specialmente quando ciò che vogliono veramente è un'operazione MERGE/ UPSERT(aggiornare le righe esistenti e crearne di nuove in cui non esiste una riga con una determinata chiave) e il DBMS non supporta merge / upsert (o non sono a conoscenza del suo supporto). Senza azioni a cascata questo è perfettamente sicuro (o si verificherà un errore quando minaccia l'integrità dei dati) ma se qualcuno lo fa per le righe in una tabella padre in cui gli FK di riferimento hannoON DELETE CASCADEimpostare quindi i dati correlati verranno eliminati come risultato dell'eliminazione iniziale e non sostituiti - quindi i dati vengono persi (non che anche se l'eliminazione e l'inserimento successivo sono racchiusi in transazioni esplicite, la cascata si verifica con l'operazione di eliminazione - non lo farà attendi di vedere se la transazione sostituisce le righe nella tabella padre nelle dichiarazioni successive) e la cascata potrebbe continuare attraverso altre navi relazionali (ad esempio: elimina un supervisore senior, il suo team viene eliminato a cascata, i team dei suoi team vengono eliminati a cascata, tutti i record tracciati per tutte quelle persone vengono eliminati a cascata, ...). Senza il collegamento a cascata abilitato, qui verrebbe visualizzato un errore anziché la perdita silenziosa dei dati.