Résumé de ce que j'ai vu jusqu'à présent :
- Certaines personnes n'aiment pas du tout la cascade.
Suppression en cascade
- La suppression en cascade peut avoir un sens lorsque la sémantique de la relation peut impliquer un "fait partie de exclusif " description. Par exemple, un enregistrement OrderLine fait partie de sa commande parente, et OrderLines ne sera jamais partagé entre plusieurs commandes. Si la commande devait disparaître, la ligne de commande devrait également disparaître, et une ligne sans commande poserait un problème.
- L'exemple canonique pour Cascade Delete est SomeObject et SomeObjectItems, où cela n'a aucun sens qu'un enregistrement d'éléments existe sans un enregistrement principal correspondant.
- Vous ne devriez pas utilisez Cascade Delete si vous préservez l'historique ou utilisez une "suppression logicielle/logique" où vous ne définissez qu'une colonne de bits supprimée sur 1/true.
Mise à jour en cascade
- La mise à jour en cascade peut être utile lorsque vous utilisez une clé réelle plutôt qu'une clé de substitution (colonne d'identité/d'incrémentation automatique) dans les tables.
- L'exemple canonique de Cascade Update est lorsque vous avez une clé étrangère mutable, comme un nom d'utilisateur qui peut être modifié.
- Vous ne devriez pas utilisez la mise à jour en cascade avec des clés qui sont des colonnes d'identité/d'auto-incrémentation.
- La mise à jour en cascade est mieux utilisée conjointement avec une contrainte unique.
Quand utiliser la cascade
- Vous souhaiterez peut-être obtenir une confirmation supplémentaire de l'utilisateur avant d'autoriser une opération en cascade, mais cela dépend de votre application.
- La mise en cascade peut vous causer des problèmes si vous configurez mal vos clés étrangères. Mais ça devrait aller si vous le faites correctement.
- Il n'est pas judicieux d'utiliser la cascade avant de bien la comprendre. Cependant, il s'agit d'une fonctionnalité utile et il vaut donc la peine de prendre le temps de la comprendre.
