Tabelle extra o chiavi esterne non specifiche?

Question

Esistono diversi tipi di oggetti in un sistema e ognuno ha la propria tabella nel database.Un utente dovrebbe essere in grado di commentare ognuno di essi.Come progetteresti le tabelle dei commenti?Mi vengono in mente alcune opzioni:

1. Una tabella dei commenti, con una colonna FK per ogni tipo di oggetto (ObjectAID, ObjectBID, ecc.)
2. Diverse tabelle di commenti, una per ogni tipo di oggetto (ObjectAComments, ObjectBComments, ecc.)
3. Un FK generico (ParentObjectID) con un'altra colonna per indicare il tipo ("ObjectA")

Quale sceglieresti?C'è un metodo migliore a cui non sto pensando?

Answer 1

@palmsey

Più o meno, ma la variazione di quello schema che ho visto più spesso viene eliminata ObjectAID et al. ParentID diventa sia PK che FK Parents.Questo ti dà qualcosa come:

• Parents

  • ParentID

• ObjectA

  • ParentID (FK e PC)
  • ColumnFromA NOT NULL

• ObjectB

  • ParentID (FK e PC)
  • ColumnFromB NOT NULL

Comments rimarrebbe lo stesso.Quindi devi solo limitare la generazione dell'ID in modo da non ritrovarti accidentalmente con un file ObjectA riga e un ObjectB riga che puntano entrambi allo stesso Parents riga;il modo più semplice per farlo è utilizzare la stessa sequenza (o qualsiasi altra cosa) per cui stai utilizzando Parents per ObjectA E ObjectB.

Vedi anche molti schemi con qualcosa come:

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

E Comments rimarrebbe invariato.Ma ora non puoi applicare tutti i tuoi vincoli aziendali (le proprietà delle sottoclassi sono tutte annullabili) senza scrivere trigger o farlo a un livello diverso.

Answer 2

È possibile progettare lo schema in modo che le tabelle commentabili (in mancanza di una parola migliore) seguano uno dei modelli standard di modellazione dell'ereditarietà?Se è così, puoi fare in modo che l'FK della tabella dei commenti punti alla tabella genitore comune.

Answer 3

@Hank Gay

Quindi qualcosa del tipo:

1. OggettoA
   • ObjectAID
   • ID genitore
2. OggettoB
   • OggettoBID
   • ID genitore
3. Commenti
   • ID commento
   • ID genitore
4. Genitori
   • ID genitore

Answer 4

Fai attenzione alle chiavi esterne generiche che non puntano esattamente a una tabella.Le prestazioni delle query risentono notevolmente se è necessario suddividere la condizione where su un tipo e puntare a diverse tabelle diverse.Se hai solo pochi tipi e il numero di tipi non aumenterà, va bene avere chiavi esterne nullable separate per le diverse tabelle, ma se avrai più tipi, è meglio trovare un modello di dati diverso (come suggerimento di @palmsey).

Answer 5

Una delle cose che mi piace fare è avere tabelle separate che colleghino la tabella generica/comune a tutte le tabelle personalizzate.

Quindi, per gli oggetti Foo e Bar e quindi i commenti su Foo & Bar, avresti qualcosa del genere:

• Pippo
  • ID cibo (PK)
• Sbarra
  • ID barra (PK)
• Commento
  • ID commento (PK)
  • Testo del commento
• FooComment
  • ID del cibo (PK FK)
  • ID commento (PK FK)
• BarCommento
  • ID barra (PK FK)
  • ID commento (PK FK)

Questa struttura:

1. Consente di avere una tabella Commenti comune
2. Non richiede un DB con ereditarietà delle tabelle
3. Non inquina le tabelle Foo e Bar con informazioni relative ai commenti
4. Consente di allegare un commento a multiplo oggetti (che possono essere desiderabili)
5. Consente di allegare altre proprietà alla giunzione di Foo/Bar e Comment, se lo si desidera.
6. Conserva ancora le relazioni con lo standard (es:veloce, semplice, affidabile) chiavi esterne