Getrennte Verknüpfungs-/Assoziationstabellen für unterschiedliche Daten?

Question

Welches ist ein besserer Gestaltungsansatz? Separate Verknüpfungs-/Assoziationstabellen für jede Art von Daten innerhalb einer Datenbank oder die Aufnahme einer allgemeinen Identität in eine gemeinsame Verknüpfungs-/Assoziationstabelle?

Da diese Frage ohne ein Beispiel wirklich keinen Sinn ergibt...

Angenommen, ich habe eine Datenbank, die Daten zu Autoren und Büchern enthält (um ein Beispiel zu verwenden, mit dem sich jeder leicht identifizieren kann). Der Einfachheit halber sehen die Tabellen für beide wie folgt aus:

Autoren

Id
Name

Bücher

Id
AuthorId
Titel
ISBN

Ich habe beschlossen, dass ich Links für diese beiden Datensätze in andere Systeme (Amazon, Barnes & Noble, Books-A-Million usw.) einfügen möchte. Ich habe Tabellen für die LinkTypes, LinkSources und LinkBases erstellt:

LinkTypes

Id
Name (z. B. Buch, Autor)

LinkSources

Id
Name (z. B. Amazon, B&N, usw.)

LinkBases

Id
LinkTypeId
LinkSourceId
UrlBase (z.B., http://www.amazon.com/book.html?id= {0})

Und eine Tabelle für die aktuellen Links:

Links

Id
LinkTypeId
LinkSourceId
ReferenceValue (dieser Wert wird in der zugehörigen UrlBase ersetzt, um den eigentlichen Link zu erstellen)

Bisher habe ich daran gedacht, getrennte Tabellen für die Links zu Autoren und Büchern zu erstellen. Die Tabellen würden etwa so aussehen:

AutorLinks

AuthorId
LinkId

Für zwei verschiedene Datentypen ist das wahrscheinlich in Ordnung, aber was passiert, wenn ich mich entschließe, die Datenbank um Verlage, Diskussionsgruppen, Genres und eine beliebige Anzahl anderer Datentypen zu erweitern, für die ich Links verfügbar haben könnte? Ist dies immer noch ein gutes Design (oder war es von Anfang an ein gutes Design)?

Eine Option, die ich in Erwägung ziehe, ist die Änderung der Tabelle "Links", um eine Spalte für "AssociationId" einzufügen, die nicht an einen bestimmten Datentyp gebunden ist, sondern dazu verwendet wird, die erforderliche Verknüpfung herzustellen. Dieser Ansatz macht die separaten Assoziationstabellen überflüssig, könnte aber langfristig zu einer gewissen Verwirrung im Design führen.

Haben Sie eine Meinung dazu, welches das bessere Design ist? Wenn ich weitere Einzelheiten angeben muss, lassen Sie es mich bitte wissen.

Answer 1

Ich habe eine ähnliche Frage gestellt und einige interessante Antworten erhalten: Gemeinsame One-to-many-Tabelle für mehrere Entitäten

Ich denke, die beste Lösung ist die Vererbung. Erstellen Sie eine abstrakte Entität (ich habe sie Item genannt, aber ich bin sicher, es gibt einen besseren Namen), die einen Autor, ein Buch oder irgendetwas anderes darstellt, das einen Link haben könnte. Sie würden am Ende mit etwas wie dieses:

Item      Author    Book       LinkBase        Link
=======   =======   =========  ==========      ========
ItemID    ItemID    ItemID     LinkBaseID      LinkBaseID
          Name      AuthorID   LinkTypeId      ItemID
                    Title      LinkSourceId    ReferenceValue
                               ReferenceValue

Ich glaube nicht, dass Sie das brauchen. LinkSourceID über die Link Tabelle, denn Sie haben bereits einen Link zurück zur LinkBase die die LinkSourceID .

Ein zusätzlicher Gedanke, den ich hatte, ist, dass, wenn referentielle Integrität wichtig ist, Sie vielleicht Ihre zweite Option vermeiden möchten, weil Sie keinen Fremdschlüssel für Ihre Links Tabelle mit einer generischen AssociationID .

Answer 2

Das sieht sehr nach einem RDF-Speicher aus, d. h. einer Graphdatenbank. Wenn dies der Fall ist, sollten Sie eine bestehende Implementierung verwenden. Wenn nicht, überdenken Sie, welche Beziehungen Sie wirklich in Ihrer Datenbank haben wollen, und schreiben Sie Ihre Tabellen so, dass sie diese erfassen.