sql en boucle fermée; Qu'est-ce qui pourrait mal se passer?

Question

Je travaille avec une base de données avec la conception suivante. J'ai lu ce n'est pas une bonne pratique d'avoir des boucles fermées dans une conception de base de données, et j'en ai plus d'un. Mais je ne me souviens pas pourquoi. Donc je ne sais pas comment cela pourrait m'affecter. Des exemples comment cela pourrait être dangereux?

Edit: a traversé mes ebooks, trouvé ce que je lisais était À partir de la base de données de conception du débutant au professionnel, éditeur: APRESS.
ils mettent simplement en garde contre cela, mais donnent une raison vague pourquoi. Non, nous n'utilisons pas de déclencheurs. Quelqu'un a une explication plus claire?
Merci Extrait, p.109:

Une petite entreprise a des employés qui travaillent chacun pour un d'un certain nombre de petits groupes de projet . Chaque groupe et tous ses employés sont logés dans une chambre particulière avec des chambres plus grandes Abritant plusieurs groups.We peut exiger des informations telles que l'endroit où chaque employé se trouve, un numéro de téléphone de l'employé particulier, où trouver un groupe particulier , quels employés travaillent dans chaque groupe, qui se trouve dans chaque pièce , et ainsi de suite. Un modèle de données possible est illustré à la Figure 5-7. Prenez un moment pour comprendre le modèle de données et les informations qu'il contient sur le nombre de groupes dans une pièce et ainsi sur ce problème particulier. Le modèle contient des informations redondantes. Est-ce que peut voir ce que c'est?

En ce qui concerne l'exemple 5-3, si nous voulons régulièrement trouver numéro de téléphone d'un employé, on peut penser que la relation top à la figure 5-7 entre employés et la pièce serait un itinéraire direct utile. Cependant, cette même information est facilement disponible par un itinéraire alternatif à travers le groupe. Nous pouvons trouver le groupe de l'employé (un seul) et ensuite trouver la salle de ce groupe (une seule seulement). Ceci est une récupération très simple (il n'implique pas toutes les complications avec des dates qui ont infesté la petite auberge dans l'exemple 5-2). Toutefois, la relation supplémentaire n'est pas tout simplement inutile, il est dangereux. Avec deux routes pour les mêmes informations , nous risquons d'obtenir deux réponses différentes sauf si les données sont très soigneusement maintenu. Chaque fois qu'un groupe de modifications modifie un groupe ou un groupe , il y a deux instances de relation à mettre à jour. Sans très prudent de mettre à jour les procédures , nous pourrions finir par avoir que Jim est dans le groupe A, qui est en chambre 12, tandis que l'autre itinéraire peut Jim ont associé directement avec salle 15. Les informations redondantes sont sujettes à des incohérences et doit toujours être supprimé.

Answer 1

Je n'avais pas eu de problèmes dans le passé en utilisant des références de "boucle fermée" entre des groupes de tables (c'est-à-dire au moins 3 dans la boucle de relation). Le seul problème que je peux penser serait si vous utilisez des déclencheurs, et même alors, ce serait seulement un problème si vous mettez à jour les autres tables dans la "boucle" dans le déclencheur.

Avez-vous une référence pour lire ce conseil pour ne pas avoir de boucles fermées?

Pour les autres qui commentait l'image peut être vu si vous copiez le lien dans une nouvelle fenêtre: http://imgur.com/ChFL1

Answer 2

Toutes les bases de données ont relation différé vérification activée et toutes les bases de données permettent d'insérer deux enregistrements dans deux tables différentes une déclaration.

Imaginez que vous avez un FOREIGN KEYA-B et B-A.

Initialement, les deux tables sont vides.

Comment allez-vous insérer le tout premier enregistrement?

Vous ne pouvez rien insérer dans A car il doit faire référence à un enregistrement dans B (qui est vide), et de la même manière vous ne pouvez rien insérer dans B.

Answer 3

Je ne dirais pas que "ce n'est pas une bonne pratique d'avoir des boucles fermées". Cependant, ils attirent l'attention sur un problème potentiel. Donc, ce serait une bonne habitude de vérifier toutes les boucles fermées pour la possibilité de ce problème.

L'exemple de manuel me semble assez clair. Il y a 2 façons dont l'emplacement/téléphone de l'employé peut être déterminée:

• employés -> Groupe -> Salle -> Téléphone
• ou employés -> Chambre -> Téléphone

C'est comme stocker deux variables pour la même chose qui doivent être synchronisées. Il y aura la possibilité que quelque chose se passe mal et les variables finissent avec des valeurs différentes - alors vous devez demander: "Lequel des deux est correct?" Par conséquent, l'exemple de livre de texte met en évidence le problème que vous devez surveiller. Cependant, le problème se résume à sémantique. C'est à dire. Que signifient les relations? Dans l'exemple de livre de texte, les deux chemins vers Room signifient exactement la même chose. Si toutefois les Group -> Room étaient simplement un «défaut» pour chaque employé parce que les employés supérieurs pouvaient obtenir leur propre chambre, ou que des employés pourraient temporairement être affectés ailleurs dans leur groupe, la relation supplémentaire serait justifiée.

Déplacement sur votre conception, voici ce que vous devez faire:

• Rechercher des groupes fermés
• Évaluer la sémantique/but/sens des relations
• Vérifiez que vous avez non seulement créé deux voies à exactement le même information.

Par exemple, vous avez:

• TestSample -> Coil -> Slab
• TestSample -> Plate -> Slab

(Pardonne la compréhension peut-être absurde de votre terminologie.) Cela signifie-t-il que votre échantillon de test peut se trouver sur deux dalles différentes en même temps? Ou est-ce que cela signifie que votre échantillon d'essai sera constitué d'une plaque et d'une bobine qui pourrait provenir (mais pas nécessairement) de différentes plaques?