Lorsque vous configurez des clés étrangères dans SQL Server, dans quelles circonstances devez-vous les cascader lors d'une suppression ou d'une mise à jour, et quel est le raisonnement sous-jacent ?
Cela s'applique probablement aussi à d'autres bases de données.
Je cherche avant tout des exemples concrets de chaque scénario, de préférence de la part de quelqu'un qui les a utilisés avec succès.
Résumé de ce que j'ai vu jusqu'à présent :
Notez que les mises à jour en cascade sont également souvent utilisées lorsque les "soi-disant" clés naturelles ne semblent pas être de véritables clés uniques. En fait, je suis convaincu que les mises à jour en cascade ne sont nécessaires qu'avec des modèles de base de données mal normalisés, et qu'elles sont une porte ouverte à des tables désordonnées et à un code désordonné.
Vous oubliez un point important : la cascade peut créer d'énormes problèmes de performance s'il y a beaucoup d'enregistrements enfants.
@HLGEM - Je ne vois pas le rapport. Si une opération en cascade provoque un ralentissement, le processus manuel équivalent provoquerait le même ralentissement ou ne serait pas correctement protégé au cas où la transaction devrait être annulée.
Les clés étrangères sont le meilleur moyen de garantir l'intégrité référentielle d'une base de données. Éviter les cascades parce qu'elles sont magiques, c'est comme écrire tout en assembleur parce qu'on ne fait pas confiance à la magie des compilateurs.
Ce qui est mauvais, c'est la mauvaise utilisation des clés étrangères, comme les créer à l'envers, par exemple.
L'exemple de Juan Manuel est l'exemple canonique, si vous utilisez du code, il y a beaucoup plus de chances de laisser de faux DocumentItems dans la base de données qui viendront vous mordre.
Les mises à jour en cascade sont utiles, par exemple, lorsque les données sont référencées par un élément susceptible de changer, comme la clé primaire d'une table d'utilisateurs qui est la combinaison nom, prénom. Vous souhaitez alors que les modifications apportées à cette combinaison se propagent partout où elles sont référencées.
@Aidan, La clarté dont vous parlez a un prix élevé : le risque de laisser des données erronées dans votre base de données, ce qui est une erreur. pas petit . Pour moi, c'est généralement le manque de familiarité avec la base de données et l'incapacité à trouver quels FK sont en place avant de travailler avec la base de données qui alimentent cette crainte. Soit cela, soit une mauvaise utilisation constante de la cascade, en l'utilisant lorsque les entités n'étaient pas conceptuellement liées, ou lorsque vous devez préserver l'historique.
L'idée était de montrer un exemple de mise à jour en cascade, mais je reconnais que ce n'est pas le meilleur exemple. L'emplacement des fichiers pourrait être un meilleur exemple.
RE : Commentaire adressé à Aidan. Non, la désactivation de CASCADE sur un FK n'augmente pas le risque de laisser des données parasites. Cela diminue le risque que plus de données que prévu soient affectées par une commande et augmente le code. Le fait d'omettre les FK laisse un risque de données parasites.
Je n'utilise jamais les suppressions en cascade.
Si je veux que quelque chose soit supprimé de la base de données, je veux lui dire explicitement ce que je veux supprimer.
Bien entendu, il s'agit d'une fonction disponible dans la base de données et il peut arriver qu'il soit utile de l'utiliser. Par exemple, si vous disposez d'un tableau "commande" et d'un tableau "élément de commande", vous pouvez souhaiter effacer les éléments lorsque vous supprimez une commande.
J'aime la clarté que j'obtiens en le faisant dans le code (ou la procédure stockée) plutôt que la "magie" qui se produit.
Pour la même raison, je ne suis pas non plus un fan des déclencheurs.
Il convient de noter que si vous supprimez une "commande", vous obtiendrez le rapport "1 ligne affectée" même si la suppression en cascade a supprimé 50 "orderItem".
Pourquoi ne pas se débarrasser également des clés primaires ? Vous auriez l'avantage de garantir des valeurs uniques dans votre code.
Plaisanterie mise à part, je travaille actuellement avec un système de base de données qui n'a pas de clés primaires définies pour les tables.
@MusiGenesis, Aidan ne préconisait pas la suppression du FK. Le FK protège toujours les données, mais sans CASCADE ON ...., la magie inattendue ne se produit pas.
Je travaille beaucoup avec des suppressions en cascade.
Il est rassurant de savoir que quiconque travaille sur la base de données ne laissera jamais de données indésirables. Si les dépendances augmentent, je modifie simplement les contraintes dans le diagramme de Management Studio et je n'ai pas besoin de modifier les sp ou les accès aux données.
Cela dit, j'ai un problème avec les suppressions en cascade, à savoir les références circulaires. Cela conduit souvent à des parties de la base de données qui n'ont pas de suppressions en cascade.
Je sais que c'est très ancien, mais +1 pour avoir mentionné le problème de référence circulaire avec CASCADE DELETE.
Pardonnez ma question de novice : que se passe-t-il réellement si vous obtenez une référence circulaire ?
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
6 votes
Cette question ne semble pas strictement liée à SQL Server et ressemble davantage à une question théorique et générale. Il serait plus utile pour la communauté que vous supprimiez l'élément
sql-serverétiquette.4 votes
@clapas Honnêtement, si je devais poser la question aujourd'hui, elle serait hors sujet. Si ce n'était pas pour le nombre élevé de vues/votes indiquant qu'elle a de la valeur pour la communauté, je l'aurais simplement supprimée.
6 votes
@JoelCoehoorn - Il est évident que ce type de questions a de la valeur. Cette valeur ne se dissipe pas avec le temps. La question qui me vient à l'esprit est de savoir quelle valeur nous perdons en interdisant ces questions aujourd'hui ?
2 votes
@P.Brian.Mackey Ici, ici ! Certaines des meilleures questions/réponses que j'ai vues sont celles qui ont été rejetées ou considérées comme étant hors sujet... mais on peut voir à l'énorme quantité de votes positifs que beaucoup ont eu exactement la même question !
0 votes
Les actions en cascade prennent des verrous sérialisables.