Mon application charge de nombreuses données d'une base de données dans une structure de données complexe. La structure de données en mémoire redresse la structure de la base de données, ce qui signifie que si la base de données contient les tableaux suivants:
Puis j'ai des cours A, B et C, et:
Cela implique que si je charge la base de données, je dois le charger dans le bon ordre. Si je charge d'abord c, alors il se plaint qu'il ne puisse pas définir la valeur C :: M_B car l'instance qu'elle doit pointer sur n'était pas chargée.
Problème est quand il y a aussi une colonne d'une clé étrangère à l'une des autres tables, disons c.
Je pourrais résoudre le problème en chargeant toutes les clés étrangères en tant que chaînes, puis effectuez une recherche après que toutes les données ont été chargées, mais que je dois parfois charger des millions d'enregistrements, je ne peux pas me permettre de passer la mémoire sur ces cordes (bien que temporaires).
Après avoir lu le bon design (par exemple, le livre "Grande échelle C ++ Software Conception") Il me semble que c'est une mauvaise idée d'avoir des références circulaires du tout. Par exemple. Si le fichier x.h inclut Y.H, mais y.h inclut également X.h, vous avez probablement une mauvaise conception; Si la classe X dépend de la classe Y et inversement que vous avez probablement une mauvaise conception, qui devrait être résolue en extrayant cette dépendance et en introduisant une troisième classe Z, qui dépend de x et y (x et y ne dépendra plus de l'autre) .
Est-il une bonne idée d'étendre cette règle de conception à la conception de la base de données? En d'autres termes: prévenir les références circulaires dans les clés étrangères.
4 Réponses :
Oui, les dépendances cycliques dans des bases de données sont une bonne excuse pour repenser la conception.
Pourquoi? Vous ne fournissez aucune justification de votre assertion.
La seule fois que vous devez avoir besoin d'une référence circulaire, c'est lorsque vous créez une structure hiérarchique, telle qu'un arbre organisationnel.
Table Employees EmployeeID <----------| SupervisorEmployeeID ---|
Vous êtes très absolu. Je peux penser à de nombreux cas plus. E.G., Qu'en est-il d'une relation 1: N où vous devez indiquer la dernière ligne supplémentaire dans le "N Set"? Ou ce que adrian smith mentionne ci-dessous. Certainement, vous pouvez contourner le besoin de la nécessité, mais vous pouvez également le faire dans votre exemple.
à partir d'une perspective de modélisation de données Il n'y a rien de fondamentalement "faux" avec une dépendance de circulation. Cela ne signifie pas que le modèle est faux.
Malheureusement, la plupart des SQL SGMS ne peuvent pas mettre en œuvre efficacement de telles contraintes, car elles ne prennent pas en charge plusieurs mises à jour de table. Habituellement, le seul moyen de suspendre temporairement une ou plusieurs contraintes temporairement (par exemple à l'aide d'une clé étrangère "repérable" ou des caractéristiques similaires) ou en modifiant le modèle pour faire une partie de la contrainte en option (mettre l'une des colonnes de référencement dans un nouvelle table). Ceci est juste une solution de contournement pour une simple limitation de SQL, cela ne signifie pas que vous avez quelque chose de mal à commencer.
Vous devez modéliser les données que vous avez. S'il y a une relation circulaire dans les données (par exemple, chaque photo appartient à un dossier; mais chaque dossier a une photo de couverture), il est correct de modeler celui-ci comme une relation circulaire dans la base de données.
Je n'ai eu que cette situation une fois lorsque vous utilisez Oracle, je n'ai donc pas eu la chance de vérifier comment mettre en œuvre une telle relation sur d'autres bases de données. Mais pour Oracle, vous pouvez lire mon article ici:
http://www.databaseandlife.com/circulaire -Dépendances-sur-étranger-clé-contraintes-oracle /