Haben diese Datenbank Design-Stile (oder anti-Muster) haben Namen?

Question

eine Datenbank mit Tabellen Produkten und Mitarbeitern in Betracht. Es gibt eine neue Anforderung aktuelle Produktmanager zu modellieren, den einzige Mitarbeiter für ein Produkt verantwortlich zu sein, unter Hinweis darauf, dass einige Produkte sind einfach oder reif genug, kein Produkt Manager zu verlangen. Das heißt, dass jedes Produkt hat null oder einen Produkt-Manager.

Ansatz. 1: alt table Product eine neue NULLable Spalte product_manager_employee_ID hinzuzufügen, so dass ein Produkt ohne Produktmanager von dem NULL Wert modelliert

Ansatz 2: Erstellen Sie eine neue Tabelle ProductManagers mit nicht-NULLable Spalten product_ID und employee_ID, mit einer einzigartigen Einschränkung für product_ID, so dass ein Produkt ohne Produktmanager durch das Fehlen einer Zeile in dieser Tabelle modelliert

Es gibt auch andere Ansätze, aber diese sind die beiden, die ich scheinen am häufigsten zu begegnen.

Unter der Annahme, diese sind beide legitime Design-Entscheidungen (wie ich geneigt bin zu glauben) und stellen lediglich Arten unterscheiden, haben sie Namen haben? Ich ziehe Ansatz 2 und finde es schwer, den Unterschied in der Art, jemand zu vermitteln, den Ansatz bevorzugt 1 ohne ein tatsächliches Beispiel unter Verwendung von (wie ich hier getan haben!) Ich würde wäre schön, wenn ich sagen könnte: „Ich bin lieber die Neigung-Richtung-6NF (oder was auch immer) Stil selbst. "

Unter der Annahme eines dieser Ansätze in der Tat ist ein Anti-Muster (wie ich nur für Ansatz kann der Fall sein, vermuten 1 durch als Attribut einer dieser Einheiten eine Beziehung zwischen zwei Entitäten Modellierung) ist diese anti-Muster haben eine nennen?

Answer 1

Nun, das erste ist nichts anderes als eine Eins-zu-viele-Beziehung (ein Mitarbeiter zu viele Produkte). Dies wird manchmal bezeichnet als O: M Beziehung (null bis viele), weil es optional ist (nicht jedes Produkt einen Produktmanager hat). Auch nicht jeder Mitarbeiter ist ein Produkt-Manager so seine optional auf der anderen Seite zu.

Die zweite ist eine Join-Tabelle, in der Regel für eine many-to-many-Beziehung verwendet. Aber da eine Seite ist nur eine Eins-zu-eins (jedes Produkt ist in der Tabelle nur einmal) es ist wirklich nur eine gewundene eine Eins-zu-viele-Beziehung.

Persönlich bevorzuge ich die erste, aber weder ist falsch (oder schlecht).

Die zweite wäre aus zwei Gründen verwendet werden, die den Sinn kommen.

1. Sie sich vorstellen, die Möglichkeit, dass ein Produkt mehr als ein Manager haben wird; oder
2. Sie wollen die Geschichte verfolgen, wer der Produktmanager für ein Produkt ist. Sie tun dies mit, sagen wir ein current_flag Spalte auf ‚Y‘ (oder ähnlich), wo nur einer nach dem anderen Strom sein kann. Dies ist eigentlich ein ziemlich häufiges Muster in Datenbank-zentrierte Anwendungen.

Answer 2

Es scheint mir, wie das Modell zwei unterschiedlichen Verhalten. Im ersten Beispiel können Sie einen Produktmanager pro Produkt und ein Mitarbeiter kann Produktmanager für mehr als ein Produkt (one to many) sein. Die zweite erscheint pro Produkt (viele zu viele) für mehr als ein Produkt-Manager zu ermöglichen. Dies würde darauf hindeuten die beiden Lösungen in verschiedenen Situationen gleichermaßen gültig sind und die Sie verwenden, würde auf der Business-Regel ab.

Answer 3

Es ist ein Fehler im ersten Ansatz. Stellen Sie sich vor für eine Sekunde, dass die Geschäftsanforderungen geändert haben und jetzt müssen Sie in der Lage sein, ein Produkt zu setzen 2 Product Manager zu. Was wirst du machen? Fügen Sie eine weitere Spalte in der Tabelle Produkt? Yuck. Das ist offensichtlich verletzt 1NF dann.

Eine weitere Möglichkeit der zweite Ansatz gibt, ist die Fähigkeit, einige Attribute für einen bestimmten Produktmanager zu speichern <-> Produkt Beziehung. Wie, wenn Sie für ein Produkt zwei Produktmanager haben, dann können Sie einen von ihnen als primärem gesetzt ... Oder zum Beispiel, ein Mitarbeiter kann eine Telefonnummer haben, aber als Produktmanager er / sie eine andere Telefonnummer haben kann ... Das gilt auch für die spezielle Tabelle dann.

Answer 4

Ansatz 1)

1. Verlangsamt die Verwendung des Produkt Tisch mit dem zusätzlichen Produktmanager Bereich (vielleicht nicht für alle Datenbanken, aber für einige).
2. Die Verknüpfung von der Product-Tabelle an die Employee-Tabelle ist einfach.

Ansatz 2)

1. Bestehende Abfragen der Produkttabelle sind nicht betroffen.
2. Erhöht die Größe der Datenbank. Sie haben nun die Produkt-ID-Säule an einem anderen Tisch sowie hinzugefügt eindeutige Einschränkungen und Indizes auf diese Tabelle dupliziert.
3. Die Verknüpfung von der Product-Tabelle zu der Tabelle Mitarbeiter mehr umständlich und teuer ist, wie Sie Tinte zu dem Zwischentisch haben zuerst.

Wie oft müssen Sie Verbindung zwischen den beiden Tabellen?

Wie viele andere Abfragen verwenden, um die Product-Tabelle?

Wie viele Datensätze in der Product-Tabelle?

Answer 5

in dem speziellen Fall, dass Sie geben, ich glaube, die Hauptmotivation für zwei Tabellen ist die Vermeidung von Nullen für fehlende Daten und das ist, wie ich die beiden Ansätze charakterisieren würde.

gibt es eine Diskussion über die Vor- und Nachteile auf wikipedia .

ich bin ziemlich sicher, dass es angesichts Abneigung c Datum dieser, er relationale Theorie definiert, so dass nur die mehrere Tabellen Lösung „gültig“ ist. zum Beispiel könnten Sie die einzelnen Tabellen approach „schlecht getippt“ nennen (da die Art von null ist unklar -. Zitat auf p4 sehen)