2010-12-06 4 views
0

Je travaille sur un système basé sur mysql pour gérer les données de traitement de produits alimentaires. À ce stade, je suis tombé sur le problème spécifique suivant:Données se référant aux deux tableaux en relation m: n

J'ai une table A avec certains éléments:

Farmer  Quantity 
Farmer A 1000 kg 
Farmer B 500 kg 

J'ai une table B qui est un m: n agregation des données du tableau A :

Batch  Quantity  Quality etc. 
LI1   200 kg  .... 
LI2   12000 kg  .... 

Pour représenter le m: n relation J'ai une table AB qui relie les deux:

FK_Farmer FK_Batch 
FarmerA  LI1 
FarmerB  LI1 
FarmerA  LI2 

Maintenant le problème: certains des lots du tableau B sont composés d'autres lots ... ce qui signifie qu'ils sont composés récursivement. Je suis interessé de savoir quelle est la meilleure approche en termes de conception de base de données pour mettre en œuvre cette situation.

Dois-je inclure une clé étrangère supplémentaire dans le tableau AB en revenant à la table des lots? Ne devrais-je pas appliquer des clés étrangères et faire référence à la fois aux agriculteurs et à la table des lots dans la même colonne (et ajouter un drapeau pour indiquer une récursivité ou quelque chose de ce genre)? Y a-t-il une autre solution évidente que j'ai trouvée?

Etre capable de faire des requêtes d'exploration descendante pour toutes les données via MySQL direct serait bien, mais n'est pas forcément requis.

+0

Les lots que je suppose ont une forme de hiérarchie, au moins pas de boucles, donc un parent ne peut pas être un descendant de lui-même? Est-ce que les lots sont également divisés, ils sont donc des descendants de plus d'un lot? – Orbling

+0

Oui, il n'y aurait pas de boucles; un lot ne peut pas descendre de lui-même. Nous avons environ 3-4 couches de produits fabriqués à partir d'autres produits et ils sont organisés dans une hiérarchie droite. Le traitement de A conduit aux produits B et C, et le traitement du produit B conduit à D, E et F. Les lots peuvent être constitués de plusieurs autres lots, oui; et un lot peut entrer dans plus d'un autre lot. Ce que je dois faire, c'est m'assurer que nous pouvons retracer les lots jusqu'à leur origine, tout en assurant que les conversions de poids etc. ne sont pas dans la portée du projet. – Stefan

Répondre

0

La manière la plus simple de représenter les données consiste à ajouter un pointeur Parent à la table Batch. La racine d'une hiérarchie aurait une valeur nulle dans ce champ. Tout non-root pointerait vers son parent, qui pourrait à son tour pointer vers un autre parent, etc., pour autant de niveaux que vous pourriez avoir.

L'interrogation d'une telle structure est délicate car SQL standard n'a aucun moyen de traiter une arborescence. Oracle a une extension propriétaire dans leur dialecte SQL, mais je ne pense pas que MySQL le fasse. Cela signifie que pour chasser l'arbre entier, vous devez soit écrire du code qui boucle sur des requêtes, soit écrire une requête qui fait plusieurs jointures pour un nombre arbitraire de niveaux maximum.

Mais je ne connais pas de solution plus simple. Fondamentalement, je prévois de chasser l'arbre avec du code plutôt qu'une seule requête.

0

Si un lot parent peut avoir plusieurs lots d'enfants, et un lot d'enfants peut avoir plusieurs lots de parents, alors vous avez besoin d'une nouvelle table de correspondance:

FK_ParentBatch FK_ChildBatch 
LI1    LI5 
LI1    LI6 
LI2    LI5 
LI2    LI3 
LI3    LI4 

Utilisez les touches étrangères pour vous assurer que les relations soient maintenues ; mais je ne sais pas si la base de données peut vous empêcher d'entrer dans les boucles, vous pourriez devoir compter sur le code ou les procs stockés pour cela.

Questions connexes