Datenbank-Design-Problem

Question

Ich versuche, eine Datenbank für einen Server und Datenbank-Inventar zu entwerfen, und ich bin für ein gutes Datenbank-Design suchen. Wir haben Tabellen für Servercluster, Stand-alone-Server und Datenbanken. Ich mag die folgenden Beziehungen in der Datenbank repräsentieren:

A one to many Beziehung von Cluster-Servern.
A one to many Beziehung von Datenbank / Server-Cluster.

Die Schwierigkeit liegt in der zweiten Beziehung becuse die Cluster und Server sind in separaten Tabellen und ein Cluster besteht aus Servern hergestellt. Was ist der beste Weg, um diese Beziehung zu vertreten?

Answer 1

Es klingt wie Sie diese in Ihrer relationalen Sicht der Situation haben.

Cluster : name, other attributes of cluster

Server : name, optional FK to cluster, other attributes of a server

Database : name, (FK to cluster OR FK to server)

Das Problem ist, dass man eine etwas komplexere reale Situation hat, eine, die relationale Technologie nicht sauber widerspiegelt.

Host -- an abstract superclass for places a database can run.

Cluster (extends Host) : name, etc.

Server (extends Host) : name, optional FK to cluster.

Database : FK to Host

Sie haben mehrere Möglichkeiten für diese Art von „Sub-Entität“ Problembehandlung.

1. Collapse Host, Cluster und Server in einer einzigen Tabelle. Dies führt zu einer rekursiven Beziehung zwischen Host (als Cluster) und Moderator (als Server). Dies ist eine Art ärgerlich, aber es hat eine einzige Tabelle für Host, Cluster und Server erstellen. Die resultierende Tabelle hat viele Nullen (Cluster Zeilen verwenden ein Bündel von Spalten, Server Zeilen verwenden, um einen anderen Satz von Spalten.) Sie haben eine Spalte hinzuzufügen unter den Sub-Entitäten von Host.

diskriminieren

2. Push-Host-Informationen nach unten in Cluster und Server. Dies ist nützlich, wenn Sie eine Menge gemeinsamer Informationen in der Host-Tabelle haben, und nur sehr wenig unterklassenspezifischen Informationen in der Cluster oder Server-Tabellen. Die Cluster und Server-Tabellen sehr ähnlich aussehen (im Wesentlichen Klone von Host) mit einem paar Spalten, die unterschiedlich sind.

3. Verwenden Sie eine Verknüpfung zwischen (Host und Cluster) oder (Host und Server), basierend auf einem Diskriminator in Host. Während ziemlich komplex, diese skaliert gut, weil alle Datenbanken auf einem Host verbunden sind, und die vollständige Liste der Hosts ist ein Zusammenschluss von Hosts, die an Server und Hosts kommen, die Cluster verbinden.

4. Verwenden Sie optional FK Felder in der Datenbank. Dies erfordert eine Verbindung zwischen Datenbank Cluster verbunden und Datenbank verbunden Server eine vollständige Liste der Datenbanken zu erhalten. Jede Datenbank haben könnte, um einen Unterscheider haben, so dass Sie zwischen den verschiedenen Kombinationen von NULL-Werte in den beiden FK Felder unterscheiden konnte. Es gibt vier mögliche Kombinationen, von denen zwei sinnvoll sind, und zwei könnten verboten werden. Der Versuch, einfach zwei gut zu verwenden, Nullable-FK ist nicht in der Regel arbeiten sie aus, so dass Sie oft eine Status-Flag benötigen Datenbank auf Cluster aus der Datenbank auf dem Server aus der Datenbank zu nichts zugewiesen zu trennen, von der Datenbank mit unbekanntem Hosting von jedem anderen Status, der sein könnte relevant.

Answer 2

Option 1: Haben zwei Felder in der Datenbanktabelle. Man bezieht sich auf Server, die anderen Cluster. Halten Sie eine von ihnen null.

Option 2: Ein weiterer Ansatz ist es, einen Eintrag in Cluster für jeden eigenständigen Server auch und Link nur für diese Tabelle hinzuzufügen

.

Option 1 ist wirklich nicht die sauberste Lösung (i mit den Kommentaren einverstanden), so geht für Option 2:)