Welche Vorteile haben wir beim Erstellen einer separaten Zuordnungstabelle für zwei relationale Tabellen?

In verschiedenen Open-Source-CMS ist mir aufgefallen, dass es eine separate Tabelle zum Zuordnen von zwei relationalen Tabellen gibt. Wie für Kategorien und Produkte gibt es eine separate product_category_mappingTabelle. Diese Tabelle enthält nur einen Primärschlüssel und zwei Fremdschlüssel aus den Kategorien und Produkttabellen.

Meine Frage ist, was sind die Vorteile dieses Datenbankdesigns, anstatt nur die Tabellen direkt durch Definieren eines Fremdschlüssels in einer der Tabellen zu verknüpfen? Ist es nur eine Frage der Bequemlichkeit?

database-design database-development

— Pankaj Upadhyay
quelle

Antworten:

Eine solche Tabelle wird häufig als Verknüpfungstabelle oder Brückentabelle bezeichnet .

Dies ist die Standardmethode zum Erstellen einer Viele-zu-Viele-Beziehung. Mit einem direkten Fremdschlüssel zwischen den beiden Tabellen können Sie nur eine Eins-zu-Viele-Beziehung (da der Primärschlüssel, auf den der Fremdschlüssel zeigt, ebenfalls eine eindeutige Einschränkung ist) oder eine Eins-zu-Eins-Beziehung (falls vorhanden) erstellen Fremdschlüssel selbst ist ebenfalls eine eindeutige Einschränkung.

Abhängig von der DB-Entwurfsphilosophie wird die Primärschlüsselspalte häufig weggelassen, und der Primärschlüssel der Brückentabelle besteht aus den beiden Fremdschlüsselspalten selbst (Sie benötigen ohnehin eine eindeutige Einschränkung für diese Spalten. Warum also nicht die Primärschlüssel?).

— tdammers
quelle

ohh k .... Kurz gesagt, wenn ich eine Viele-zu-Viele-Beziehung haben muss, muss man diesem Ansatz folgen, oder?

— Pankaj Upadhyay

@PankajUpadhyay: Richtig. MM-Beziehungen sollen auf diese Weise implementiert werden.

— NoChance

@PankajUpadhyay: Theoretisch können Sie andere Ansätze verwenden, aber sie sind chaotisch und falsch. Ich schlage vor, Sie gehen nie dorthin.

— tdammers

@PankajUpadhyay: Wenn Sie eine normalisierte Datenbank erstellen möchten, müssen Sie wie erläutert eine dritte Tabelle verwenden. Wenn Sie eine 1-M-Beziehung haben, möchten Sie definitiv keinen dritten Tisch. Wenn Sie ein endliches und begrenztes MM haben und sich nicht für die Normalisierung interessieren, können Sie auf eine dritte Tabelle verzichten. Halten Sie sich im Allgemeinen an eine normalisierte Datenbank, es sei denn, Sie erstellen ein Data Warehouse oder einen Data Mart (in solchen Fällen ist ein normalisiertes Schema umstritten).

— NoChance

@EmmadKareem: Ja, ich habe das gesehen ... Meine Anforderungen sind eins zu viele, also werde ich den Tisch nicht erstellen ... Danke Kumpel

— Pankaj Upadhyay

Dies ist eine einfache Möglichkeit, viele-zu-viele- Beziehungen zu implementieren .

Betrachten Sie diese beiden Tabellen:

category
--------
categoryID [PK]
categoryName

product
-------
productID [PK]
productName

Wenn Sie ein categoryIDFeld hinzufügen product, kann jedes Produkt nur eine Kategorie haben. Aber wenn wir so etwas haben product_category_mapping:

product_category_mapping
------------------------
mappingID [PK]
productID [FK]
categoryID [FK]

dann können wir haben:

mappingID  productID  categoryID
--------------------------------
1          1          1
2          1          2
3          2          3
4          2          1

Produkt 1 gehört also zur Kategorie 1 & 2 und Produkt 2 gehört zur Kategorie 3 & 1, so dass viele Produkte zu vielen Kategorien gehören und viele Kategorien viele Produkte haben.

Wie tdammers schreibt , wird diese Tabelle oft als Link-Tabelle oder Bridge-Tabelle bezeichnet, und ich habe sogar gesehen, dass sie als HABTM-Tabelle von HasAndBelongsToMany bezeichnet wird, die anscheinend Ruby on Rails ist und für viele bis viele spricht. Und Wikipedia nennt es eine Kreuzungstabelle und hat noch einige weitere Namen dafür.

— Yannis
quelle

Es ist nicht nur Rails-Sprache, praktisch alle PHP-Frameworks, die ich verwendet habe, bezeichnen es als HABTM.

— Sevenseacat

@ Karpie Einige Beispiele? Ich weiß, dass CakePHP den Namen HABTM verwendet, aber es begann als Rails-Klon.

— Yannis

Ich bin ein großer Fan von Leihmutterschaften. Ich ziehe es jedoch vor, den zusätzlichen Ersatzschlüssel "MappingID" wegzulassen und eine zusammengesetzte PK auf "productID" und "categoryID" zu setzen. In meinen Augen ist der zusammengesetzte Schlüssel, der aus 2 Ersatzzeichen besteht, ein eigenständiges Ersatzzeichen. Sie werden niemals die Ersatz-Mapping-ID in einem Join verwenden.

— Lord Tydus

@ LordTydus Ich habe nicht wie tdammers über den zusammengesetzten Schlüssel geschrieben, es hat keinen Sinn, seine Antwort zu recyceln. Es gibt jedoch gültige Verwendungszwecke für den mappingIDSchlüssel. Ein häufiges Szenario besteht darin, den massiven Import / Export besser zu verfolgen, wenn die Junction-Tabelle viele Fremdschlüssel enthält.

— Yannis

Der Grund für die Verwendung einer Zuordnungstabelle besteht darin, Doppelarbeit zu vermeiden. Probieren Sie eine andere Mapping-Technik aus. Ohne diese Daten können Sie doppelte Daten nicht verhindern.

Und das bringt eine 2-CD-Frage. Warum sollten Sie sich die Mühe machen, Doppelarbeit zu vermeiden? Sie müssen die Daten also nur einmal an einem Ort bearbeiten. Manchmal gibt es Leistungseinbußen, um Doppelarbeit zu vermeiden. In anderen Fällen steigt die Leistung, um Doppelarbeit zu vermeiden. Zum Beispiel ist es schneller, eine Dropdown-Liste mit normalisierten Suchwerten zu füllen, als unterschiedliche doppelte Werte in einer großen Tabelle auszuwählen.

— Lord Tydus
quelle