Datenreferenzierung auf beide Tabellen in m: n-Beziehung

Ich arbeite an einem MySQL-basierten System, um Daten aus der Verarbeitung von Lebensmitteln zu verwalten. An dieser Stelle ich auf das folgende spezifische Problem kam:Datenreferenzierung auf beide Tabellen in m: n-Beziehung

habe ich eine Tabelle A mit einigen Einzelteilen:

Farmer  Quantity 
Farmer A 1000 kg 
Farmer B 500 kg

Dann habe ich eine Tabelle B, die ein m: n agregation der Daten von Tabelle A :

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

die m darstellen kann: n Beziehung habe ich eine Tabelle AB, die die beiden verbindet:

FK_Farmer FK_Batch 
FarmerA  LI1 
FarmerB  LI1 
FarmerA  LI2

Jetzt das Problem: einige der Stapel in Tabelle B bestehen tatsächlich aus anderen Stapeln ... was bedeutet, dass sie rekursiv zusammengesetzt sind. Ich bin interessiert zu wissen, was der beste Ansatz in Bezug auf Datenbankdesign ist, um diese Situation zu implementieren.

Sollte ich einen zusätzlichen Fremdschlüssel in die Tabelle AB aufnehmen, der auf die Stapeltabelle verweist? Sollte ich keine Fremdschlüssel durchsetzen und sowohl die Landwirte als auch die Stapeltabelle durch die gleiche Spalte referenzieren (und ein Flag hinzufügen, um Rekursion oder etwas anzuzeigen)? Gibt es noch eine andere offensichtliche Lösung?

In der Lage, Drill-Down-Abfragen für alle Daten durch direkte MySQL zu tun wäre schön, aber nicht unbedingt erforderlich.

Quelle

2010-12-06 Stefan

Die Chargen, die ich annahm, haben irgendeine Form von Hierarchie, zumindest keine Schleifen, also kann ein Elternteil kein Nachkomme von sich selbst sein? Werden Batches überhaupt aufgeteilt, sodass sie von mehr als einem Batch abstammen? – Orbling

Ja, es gäbe keine Schleifen; Eine Charge kann nicht von selbst absteigen. Wir haben etwa 3-4 Schichten von Produkten aus anderen Produkten und sie sind in einer geraden Hierarchie organisiert. Die Verarbeitung von A führt zu Produkten B und C, und die Verarbeitung von Produkt B führt zu D, E und F. Chargen können aus mehreren anderen Chargen bestehen, ja; und eine Charge kann in mehr als eine andere Charge gehen. Was ich tun muss, ist sicherzustellen, dass wir die Chargen zurück zu ihrem Ursprung verfolgen können, während die Gewichtskonvertierung usw. nicht im Rahmen des Projekts ist. – Stefan

Die einfachste Möglichkeit zum Darstellen der Daten besteht darin, der Batch-Tabelle einen übergeordneten Zeiger hinzuzufügen. Der Stamm einer Hierarchie würde in diesem Feld eine Null haben. Alle Nicht-Root-Benutzer verweisen auf ihren übergeordneten Server, der wiederum auf einen anderen übergeordneten Server usw. für so viele Ebenen verweist, wie Sie möglicherweise haben.

Das Abfragen einer solchen Struktur ist schwierig, da Standard-SQL keine Möglichkeit bietet, einen Baum zu verarbeiten. Oracle hat eine proprietäre Erweiterung in ihrem SQL-Dialekt, aber ich denke nicht, dass MySQL dies tut. Das bedeutet, dass Sie, um den gesamten Baum zu verfolgen, entweder Code schreiben müssen, der Abfragen durchläuft, oder Sie müssen eine Abfrage schreiben, die mehrere Joins für eine beliebige Anzahl von maximalen Ebenen ausführt.

Aber ich kenne keinen einfacheren Weg. Grundsätzlich würde ich den Baum lieber mit Code als mit einer einzigen Abfrage verfolgen.

Quelle

2010-12-06 19:53:22 Jay

Wenn ein Elternteil Batch mehrere untergeordnete Chargen haben kann, und ein Kind Charge kann mehrere übergeordnete Chargen haben, dann müssen Sie eine neue Zuordnungstabelle:

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

Verwenden Fremdschlüssel, um sicherzustellen, dass die Beziehungen aufrechterhalten werden ; Aber ich weiß nicht, ob die Datenbank verhindern kann, dass Sie in Schleifen geraten, Sie müssen sich möglicherweise auf Code oder gespeicherte Prozeduren verlassen.

Quelle

2010-12-08 12:56:09

Datenreferenzierung auf beide Tabellen in m: n-Beziehung

Antwort

Verwandte Themen