Zirkuläre Abhängigkeiten in Fremdschlüsseln: Verwenden oder vermeiden?

Meine Anwendung lädt viele Daten aus einer Datenbank in eine komplexe Datenstruktur. Die speicherinterne Datenstruktur ähnelt der Struktur der Datenbank, dh, wenn die Datenbank die folgenden Tabellen enthält:

table A, Schlüssel ist A1Tabelle B, Schlüssel ist B1, eine der Spalten ist ein Fremdschlüssel für [den Schlüssel von] Tabelle ATabelle C, Schlüssel ist C1, eine der Spalten ist ein Fremdschlüssel für [den Schlüssel von] Tabelle B

Dann habe ich die Klassen A, B und C und:

in Datenelement von B (B :: m_a) ist ein Zeiger auf Ain Datenelement von C (C :: m_b) ist ein Zeiger auf B

Dies impliziert, dass ich die Datenbank in der richtigen Reihenfolge laden muss, wenn ich sie lade. Wenn ich zuerst C lade, wird es sich beschweren, dass es den Wert C :: m_b nicht setzen kann, weil die Instanz, auf die es zeigen sollte, nicht geladen wurde.

Problem ist, wenn es in A auch eine Spalte gibt, die ein Fremdschlüssel für eine der anderen Tabellen ist, sagen wir C.

Ich könnte das Problem lösen, indem ich alle Fremdschlüssel als Zeichenfolgen lade und dann eine Suche durchführe, nachdem alle Daten geladen wurden. Da ich jedoch manchmal Millionen von Datensätzen laden muss, kann ich es mir nicht leisten, Speicher für diese zu verwenden (auch wenn temporäre) Zeichenfolgen.

achdem ich über gutes Design gelesen habe (z. B. das Buch "Large Scale C ++ Software Design"), scheint es mir eine schlechte Idee zu sein, Zirkelverweise zu haben. Z.B. Wenn die Datei X.H Y.H enthält, aber Y.H auch X.H enthält, haben Sie wahrscheinlich ein schlechtes Design. Wenn Klasse X von Klasse Y abhängt und umgekehrt, haben Sie wahrscheinlich ein schlechtes Design, das gelöst werden sollte, indem Sie diese Abhängigkeit extrahieren und eine dritte Klasse Z einführen, die von X und Y abhängt (X und Y hängen nicht mehr voneinander ab). .

Ist es eine gute Idee, diese Entwurfsregel auch auf das Datenbankdesign auszudehnen? Mit anderen Worten: Zirkelverweise in Fremdschlüsseln verhindern.

Antworten auf die Frage(8)

Ihre Antwort auf die Frage