Könnte diese zirkuläre Datenreferenz besser entworfen werden?

Question

Ich habe Daten über Farben. Einige dieser Farben bestehen aus einer Anzahl von Farben kombiniert. Eine dieser Kombinationen kann theoretisch eine andere kombinierte Farbe sein. Im Fall einer kombinierten Farbe muss ich einige Attribute über die "Kind" -Farben definieren.

ich meine Datenbank zur Zeit haben wie so definiert:

COLOR 
!Id 
+MultiColorGroupId 

MULTICOLOR 
    !Id 
    +MultiColorGroupId 
    +ColorId 
    +Type 

Diese enthält alle Informationen, kann ich in einem ziemlich klaren Weg brauchen. Das einzige, was ich denke, dass passieren könnte, ist, dass ich einen Zirkelverweis bekomme, wo sich eine Farbe als childColor befindet. Gegenwärtig besteht die einzige Möglichkeit, dies zu erkennen, darin, eine Überprüfung der Einfügung entweder in der Datenbank oder in der Anwendung zu erstellen. Da die Kreisreferenz beliebig tief sein könnte und die aktuelle Struktur möglicherweise ziemlich breit sein könnte, würde ich eine deterministischere Datenstruktur bevorzugen.

Gibt es bessere Möglichkeiten, dies zu definieren?

Answer 1

Wenn die Tiefe beliebig sein kann, dann können Sie das Problem in der Datenstruktur nicht lösen. Eine Sache zu betrachten ist, wenn es ein Problem ist, wenn die Selbstreferenz tatsächlich in der Datenbank gespeichert wird. Vielleicht sollte es an dem Abrufcode liegen, um sicherzustellen, dass die Daten nicht unendlich gelesen werden.

Ich hatte ein ähnliches Problem mit Essen Rezepte. Es braucht Joghurt, um Joghurt zu machen (um ein allgemeines Beispiel zu wählen), also mussten wir diese Speicherung unterstützen und Logik auf den Abruf setzen, um sicherzustellen, dass ein bestimmter Inhaltsstoff nur einmal explodiert.

Answer 2

Wenn Sie eine Schnittstelle (außer SQL) zu diesen Tabellen haben, können Sie leicht alle "illegalen" Optionen von den verfügbaren Auswahlen ausschließen. Andernfalls könnten On-Insert- und On-Update-Trigger oder Check-Constraints verwendet werden.

Answer 3

Ich denke, Sie müssen dies in Code tun, obwohl ich vor Triggern warnen - wie Sie darauf hinweisen, die Kosten der Trigger werden viel schlechter sein als eine lineare Beziehung abhängig davon, wie komplex Ihre Strukturen sind.

In Code mit einer Sammlung ist es ein sehr einfaches Problem zu lösen.

Wirklich Ihre Tabellendefinitionen können dieses Szenario nicht definieren, es ist eine Regel, die eine Eigenschaft der Daten selbst ist, nicht die Speicherstruktur.

Wie für die Datenstruktur, kam ich mit der gleichen Struktur.