Maison >base de données >tutoriel mysql >Les contraintes référentielles circulaires dans SQL sont-elles valides et comment peuvent-elles être résolues ?

Les contraintes référentielles circulaires dans SQL sont-elles valides et comment peuvent-elles être résolues ?

Barbara Streisand
Barbara Streisandoriginal
2024-11-28 16:47:15176parcourir

Are Circular Referential Constraints in SQL Valid, and How Can They Be Resolved?

Contraintes référentielles circulaires en SQL : naviguer dans les complexités

Dans la conception de bases de données, l'établissement de relations entre les tables via des contraintes de clé étrangère est une pratique courante. Cependant, lorsque des tables se référencent les unes les autres dans une boucle, créant une dépendance circulaire, cela soulève la question : un tel schéma est-il valide ?

Exemple de référence circulaire

Considérons le schéma suivant où deux tables, products et products_pictures, se référencent mutuellement :

CREATE TABLE products (
  ID int(10) unsigned NOT NULL AUTO_INCREMENT,
  DEFAULT_PICTURE_ID int(10) unsigned DEFAULT NULL,
  FOREIGN KEY (DEFAULT_PICTURE_ID) REFERENCES products_pictures (ID) ON DELETE SET NULL ON UPDATE SET NULL
);

CREATE TABLE products_pictures (
  ID int(10) unsigned NOT NULL AUTO_INCREMENT,
  PRODUCT_ID int(10) unsigned NOT NULL,
  FOREIGN KEY (PRODUCT_ID) REFERENCES products (ID) ON DELETE CASCADE
);

Dans cette conception, products.DEFAULT_PICTURE_ID fait référence à products_pictures.ID et products_pictures.PRODUCT_ID renvoient à products.ID, créant une référence circulaire.

Validité et implications

Le consensus général parmi les experts est que les références circulaires dans les schémas de base de données ne sont pas recommandées. . Ils peuvent entraîner des complexités et des incohérences lors de l'exécution d'opérations de base de données telles que des insertions et des mises à jour.

Option 1 : Colonne de clé étrangère nullable

Pour résoudre ce problème, une option consiste à autoriser یکی از si les deux colonnes de clé étrangère peuvent être nullables. Cela résout le problème de la « poule et de l’œuf » : dans quelle table insérer les données en premier. Cependant, cela introduit un problème d'intégrité des données lorsqu'un produit peut avoir une image par défaut qui appartient à un autre produit.

Option 2 : colonne IsDefault

Une autre approche consiste à supprimer la colonne DEFAULT_PICTURE_ID des produits et ajoutez une colonne de bits IsDefault dans products_pictures. Cela permet à une seule image par produit d'avoir le bit IsDefault défini.

Option 3 : Contraintes reportables

Les contraintes reportables permettent de vérifier et d'appliquer certaines contraintes ultérieurement, résolvant ainsi la question de la référence circulaire. Cette option n'est pas prise en charge dans MySQL.

Option 4 : Table séparée pour les images par défaut

Pour éliminer les dépendances circulaires et garantir l'intégrité des données, envisagez de créer une table distincte, telle que comme product_default_picture, qui stocke la relation produit-image par défaut. Cette approche permet aux deux colonnes de clé étrangère d'être non nullables.

En conclusion, même si les références circulaires peuvent être techniquement valides dans certains systèmes de bases de données, elles sont généralement déconseillées. Considérez les options présentées ci-dessus pour traiter les références circulaires dans vos schémas MySQL et garantir l'intégrité des données.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn