Quando due tabelle sono molto simili, quando dovrebbero essere combinate?

Question

Ho eventi e foto e quindi commenti per entrambi. Al momento, ho due tabelle di commenti, una per i commenti relativi agli eventi e l'altra per i commenti alle foto. Schema è simile a questo:

CREATE TABLE EventComments 
(
    CommentId int, 
    EventId int, 
    Comment NVarChar(250), 
    DateSubmitted datetime 
) 

CREATE TABLE PhotoComments 
(
    CommentId int, 
    PhotoId int, 
    Comment NVarChar(250), 
    DateSubmitted datetime 
) 

Le mie domande è se io li combinano, e aggiungere una tabella di riferimento trasversale a parte, ma non riesco a pensare ad un modo per farlo correttamente. Penso che questo dovrebbe essere OK, quali sono i tuoi pensieri?

Modifica

in base alla risposta di Walter (e qualche lettura leggera), mi è venuta in mente questo:

CREATE TABLE Comments 
(
    CommentId int, 
    Comment NVarChar(250), 
    DateSubmitted datetime 
    CONTRAINT [PK_Comments] PRIMARY KEY 
    (
    CommentId 
) 
) 

CREATE TABLE EventComments 
(
    CommentId int, 
    EventId int 
) 

CREAT TABLE PhotoComments 
(
    CommentId int, 
    PhotoId int 
) 

ALTER TABLE EventComments ADD CONSTRAINT FK_EventComments FOREIGN KEY (CommentId) REFERENCES Comments(CommentId) 

ALTER TABLE PhotoComments ADD CONSTRAINT FK_PhotoComments FOREIGN KEY (CommentId) REFERENCES Comments(CommentId) 

ci sono davvero differenze di prestazioni tra le strutture? Per me, sembra un po 'una preferenza. Vedo i vantaggi nel secondo schema, se voglio aggiungere una certa specificità ai commenti degli eventi o ai commenti delle foto, ho una tabella separata per farlo, e se voglio entrambi condividere una nuova proprietà, c'è una sola tabella per aggiungi la nuova proprietà.

Answer 1

Commenti, PhotoComment e EventComment sono correlati in un modello denominato "specializzazione di generalizzazione". Questo modello è gestito da una semplice ereditarietà nei linguaggi orientati agli oggetti. È un po 'più complicato impostare uno schema di tabelle che catturerà lo stesso modello.

Ma è ben compreso. Una rapida ricerca su google su "modellazione relazionale di specializzazione di generalizzazione" ti darà parecchi buoni articoli sull'argomento.

Answer 2

È possibile combinarli e aggiungere un campo che indica se è per una foto o un evento.

Avrete bisogno di due chiavi esterne; uno per le foto e uno per gli eventi, ma averli in una tabella consente di scrivere un singolo set di codice per gestire tutti i commenti.

Ma sono distrutto. È più pulito se si tiene separati, a condizione di non dover mai mescolare i due tipi di commenti nella stessa lista (che richiederebbe UNION).

Answer 3

Il mio stile personale di progettazione sarebbe quello di combinarli, quindi aggiungere un flag intero per indicare a cosa serve il commento. Ciò mi darebbe anche scalabilità nel caso in cui volessi aggiungerne altri in seguito.

Answer 4

Se li unisci, rovinerà la struttura della chiave. Dovrai avere chiavi esterne nulle o una struttura chiave "soft" di chiave e tipo. Li terrei separati.