it-swarm.com.de

Ob separate Tabellen für verschiedene Produkttypen erstellt werden sollen oder nicht?

Ich bin gerade dabei, eine Datenbank zu entwerfen, und habe Bedenken hinsichtlich meiner anfänglichen Entwurfsentscheidungen ...

Folgende Produkttypen stehen zur Verfügung ... Modelle, Teile, Ersatzteilsätze und Optionen.

Option A (erstes Design): Ich plante separate Tabellen für die oben genannten Produkttypen. Ich würde sagen, dass 75% der Felder in jeder Tabelle gleich sind.

Ich habe jeden Produkttyp aufgrund der Assoziationen, die ich zwischen ihnen erstellen muss, als separate Tabellen erstellt. Beispielsweise kann ein Modell viele Optionen haben und eine Option kann viele Modelle haben. Eine Option kann auch viele Teile haben und ein Teil kann viele Optionen haben ... und so weiter ...

Option B: Anstatt separate Tabellen zu haben, könnte ich eine Tabelle mit dem Namen Produkt erstellen, die Modell-, Teil-, Ersatzteil-Kits und Optionen umfasst. Ich könnte ein Feld namens Typ haben, um zwischen Modell, Optionen usw. zu unterscheiden. Ich nehme an, ein Nachteil ist, dass für bestimmte Produkttypen niemals mehrere Felder verwendet werden (links null). Ich vermute, hier würden "nicht Best Practices" ins Spiel kommen.

Option B würde die Komplexität des Datenbankdesigns erheblich reduzieren. Ich müsste mich auch nicht darum kümmern, auf eine Reihe von Tabellen zu verweisen, wenn ich Daten für Abfragen abrufe ...

25
payling

Wenn dies meine Entwurfsentscheidung wäre, würde ich wahrscheinlich eher eine Option C (modifizierte Option a) wählen.

Erstens, warum nicht 'Option B':

Zum einen gefällt mir die Klarheit, dass jedes Produkt seinen eigenen Tisch hat. Wenn es sich nur um eine große Tabelle mit einem Feld zur Bestimmung des Typs handelt, ist die Beziehung nicht so klar.

Zum anderen würde die Indizierungsstrategie immer erfordern, dass dieses Typfeld aufgelistet wird. Da es sich nur um 4 Typen handelt, ist die Indexkardinalität extrem niedrig (SELECT * FROM product_table WHERE type='X' führt im Grunde sowieso einen vollständigen Tabellenscan durch)

Option C.

  • Erstellen Sie eine übergeordnete Tabelle, die nur die Spalten enthält, die alle Typen gemeinsam nutzen
  • Erstellen Sie jeden Produkttyp als eigene Tabelle mit ihren einzelnen Spalten, mit einem zusätzlichen: Ein Link zur übergeordneten Tabelle
  • Erstellen Sie jede 'Link'-Tabelle: Product_Option, Model_option usw. mit Links zu den jeweiligen Schlüsseln.
  • Für diejenigen mit wechselseitigen Links (MODEL_OPTION, OPTION_MODEL) erstellen Sie auch diese Tabellen. Dies erhöht die Klarheit Ihrer Joins für alle, die sich das ansehen.

Der Nachteil ist die Komplexität, sicherzustellen, dass Waisen vermieden werden, wenn Dinge aktualisiert/gelöscht werden, und zunächst die Abfragen zu entwerfen, die diese Tabellen verwenden.

8
Derek Downey

Ich würde vorschlagen, dass Sie mit dem "richtigen" relationalen Modell beginnen, Ihrer Option A. Wenn die typische Verwendung dieses Modells Sie in einigen Bereichen zur Denormalisierung führt, haben Sie keine Angst davor.

Ich habe letzte Woche mit einem Kollegen darüber gesprochen, wie Schemaentwürfe oft als etwas angesehen werden, das in Stein gemeißelt ist und sich nie ändern kann. Seltsam, wenn man bedenkt, wie Refactoring in jeder anderen Schicht einer Anwendung in der Praxis akzeptiert wird, wird das Refactoring eines Datenbankschemas immer noch als unpraktisch angesehen.

Wenn die Schnittstelle zur Datenbank gut gestaltet ist, hindert Sie nichts daran, das Schema anzupassen, wenn Sie mehr über die Verwendungsmuster des Systems erfahren.

7

Dies klingt sehr ähnlich zu den Stücklisten/Mehrfachkardinalitäten , die Paul Neilsen in Kapitel 17 von Die SQL Server 2008-Bibel .

Das gesamte Kapitel ist sehr gut gelesen und der spezifische Abschnitt, der sich mit Ihrem Viele-zu-Viele-Problem befasst, befindet sich auf den Seiten 416-419.

Dies ist die beste Diskussion, die ich über den Typ explodierter Teile des Datendesigns gesehen habe.

Wenn Sie sich ein wahrscheinliches Szenario vorstellen können, in dem häufig Abfragen für alle vier Produkttypen durchgeführt werden (und das scheint mir wahrscheinlich), ist Ihre Option B die beste.

Anstatt viele nicht verwendete nullfähige Felder in der Produkttabelle zu belassen, fügen Sie eine ModelProduct-Tabelle, eine PartProduct-Tabelle, eine ReplacementPartKitProduct-Tabelle hinzu und haben nur die Felder, die für diese Typen in diesen Tabellen unterschiedlich sind. Verwenden Sie für diese Tabellen denselben Primärschlüssel wie für Ihre Produkttabelle. Fügen Sie der Product- und ModelProduct-Tabelle hinzu, wenn Sie mit Models arbeiten möchten. Müssen Sie feststellen, ob der Produktdatensatz, den Sie haben, ein Teil ist? Führen Sie einfach eine Linksverknüpfung von Product zu PartProduct durch. Wenn PartProduct. [PrimaryKey] nicht null ist, haben Sie ein Part. Wenn es null ist, ist es kein Teil. Alternativ können Sie der Product-Tabelle ein ProductType-Feld hinzufügen.

0
Alan McBee