Zusätzliche Tabellen oder unspezifische Fremdschlüssel?

Question

Es gibt mehrere Arten von Objekten in einem System und jedes hat seine eigene Tabelle in der Datenbank.Ein Benutzer sollte in der Lage sein, jeden von ihnen zu kommentieren.Wie würden Sie die Kommentartabelle(n) gestalten?Mir fallen ein paar Möglichkeiten ein:

1. Eine Kommentartabelle mit einer FK-Spalte für jeden Objekttyp (ObjectAID, ObjectBID usw.)
2. Mehrere Kommentartabellen, eine für jeden Objekttyp (ObjectAComments, ObjectBComments usw.)
3. Ein generisches FK (ParentObjectID) mit einer weiteren Spalte zur Angabe des Typs („ObjectA“)

Welches würdest du nehmen?Gibt es eine bessere Methode, an die ich nicht denke?

Answer 1

@palmsey

Ziemlich viel, aber die Variation dieses Musters, die ich am häufigsten gesehen habe, wird beseitigt ObjectAID et al. ParentID wird sowohl zum PK als auch zum FK Parents.Das bringt Ihnen so etwas wie:

• Parents

  • ParentID

• ObjectA

  • ParentID (FK und PK)
  • ColumnFromA NOT NULL

• ObjectB

  • ParentID (FK und PK)
  • ColumnFromB NOT NULL

Comments würde gleich bleiben.Dann müssen Sie nur noch die ID-Generierung einschränken, damit Sie nicht versehentlich mit einer enden ObjectA Reihe und ein ObjectB Zeile, die beide auf dasselbe zeigen Parents Reihe;Der einfachste Weg, dies zu tun, besteht darin, dieselbe Sequenz (oder was auch immer) zu verwenden, für die Sie sie verwenden Parents für ObjectA Und ObjectB.

Sie sehen auch viele Schemata mit etwa:

• Parents
  • ID
  • SubclassDiscriminator
  • ColumnFromA (nullable)
  • ColumnFromB (nullable)

Und Comments würde unverändert bleiben.Aber jetzt können Sie nicht alle Ihre Geschäftsbeschränkungen durchsetzen (die Eigenschaften der Unterklassen sind alle nullbar), ohne Trigger zu schreiben oder dies auf einer anderen Ebene zu tun.

Answer 2

Ist es möglich, das Schema so zu entwerfen, dass die kommentierbaren Tabellen (mangels eines besseren Wortes) einem der Standardmuster für die Vererbungsmodellierung folgen?Wenn ja, können Sie den FK der Kommentartabelle auf die gemeinsame übergeordnete Tabelle verweisen lassen.

Answer 3

@Hank Gay

Also so etwas wie:

1. ObjektA
   • ObjectAID
   • Eltern ID
2. ObjektB
   • ObjektBID
   • Eltern ID
3. Kommentare
   • Kommentar-ID
   • Eltern ID
4. Eltern
   • Eltern ID

Answer 4

Seien Sie vorsichtig mit generischen Fremdschlüsseln, die nicht auf genau eine Tabelle verweisen.Die Abfrageleistung leidet erheblich, wenn Sie die Where-Bedingung für einen Typ aufteilen und auf mehrere verschiedene Tabellen verweisen müssen.Wenn Sie nur wenige Typen haben und die Anzahl der Typen nicht zunimmt, ist es in Ordnung, separate Nullable-Fremdschlüssel für die verschiedenen Tabellen zu haben. Wenn Sie jedoch mehr Typen haben, ist es besser, ein anderes Datenmodell zu entwickeln (z. B @palmseys Vorschlag).

Answer 5

Eines der Dinge, die ich gerne mache, ist, separate Tabellen zu haben, die die generische/gemeinsame Tabelle mit allen individualisierten Tabellen verknüpfen.

Für die Objekte Foo und Bar und dann Kommentare zu Foo & Bar hätten Sie also etwa Folgendes:

• Foo
  • Foo-ID (PK)
• Bar
  • Bar-ID (PK)
• Kommentar
  • Kommentar-ID (PK)
  • Kommentartext
• FooComment
  • Foo-ID (PK FK)
  • Kommentar-ID (PK FK)
• BarKommentar
  • Bar-ID (PK FK)
  • Kommentar-ID (PK FK)

Diese Struktur:

1. Ermöglicht Ihnen eine gemeinsame Kommentartabelle
2. Erfordert keine Datenbank mit Tabellenvererbung
3. Verunreinigt die Foo- und Bar-Tische nicht mit kommentarbezogenen Informationen
4. Ermöglicht das Anhängen eines Kommentars mehrere Objekte (die begehrenswert sein können)
5. Ermöglicht Ihnen, bei Bedarf weitere Eigenschaften an die Verbindung von Foo/Bar und Comment anzuhängen.
6. Behält weiterhin die Beziehungen zum Standard bei (d. h.:schnell, einfach, zuverlässig) Fremdschlüssel