Progettazione del database per comportamento generico

Ci sono diversi modi per risolvere questo problema, ad esempio:

Elaborazione della soluzione 1

Per ogni tipo di cosa commentabile (tabella i.e.) nel tuo database, avresti una colonna commentSet .

La prima volta che un utente invia un commento per un elemento specifico (cioè riga), crei un nuovo commentSetid e metti tutti i commenti successivi sullo stesso oggetto nella tabella dei commenti con lo stesso set. Ovviamente, memorizzerai per ogni timestamp e id utente.

Questo approccio è flessibile. L'unico vincolo è prevedere la colonna commentSet dove necessario. Quando si visualizzano gli oggetti, è molto veloce trovare i commenti correlati. È anche molto facile trovare tutti i contributi di un utente specifico.

Lo svantaggio principale sarà quello di ritrovare gli elementi commentati (quando si avvia la navigazione da un utente o un set di commenti. Qui dovresti cercare ogni potenziale tabella che abbia una colonna commentSet. Questo potrebbe rallentare notevolmente la ricerca .

C'è una via d'uscita: nel commentSet inserisci un identificatore di classe (ad esempio qualcosa che identifichi in modo univoco la tabella contenente l'elemento da commentare). Anche se questo sarebbe facile da usare in modo programmatico, non è così bello, perché questo è molto difficile da usare nelle query SQL.

Elaborazione della soluzione 2

Questo è un buon modo per indirizzare la navigazione bidirezionale tra elementi e commenti commentabili. Il motore relazionale dovrebbe gestirlo molto velocemente.

Il problema è che la tua tabella dei commenti dipende da tutte le altre tabelle commentabili. Ogni volta che crei una nuova classe / tabella commentabile, dovrai aggiornare anche la gestione dei commenti ... Non è nel senso di separazione delle preoccupazioni.

Inoltre, se hai molti oggetti diversi che possono essere commentati, avresti molte colonne vuote nella tabella dei commenti.

Ma va bene. Di fatto questa è un'implementazione del ereditarietà di tabelle singole modello di mappatura relazionale dell'oggetto.

altre soluzioni

Potresti anche considerare altri modelli orm come ereditarietà di tabelle concrete o mappatori di ereditarietà.

Manca un'altra possibile soluzione, che è simile alla seguente:

Comment
 - id
 - body
 - subject_id
 - subject_type

Il campo subject_id conterrà l'ID di o un utente, un post o qualsiasi altra cosa che possa essere commentata. E la colonna subject_type sarebbe un enum che indica se si tratta di un utente, di un post o di qualsiasi altra cosa. Questa è, per quanto ne so, la più normalizzata delle possibili soluzioni.

Questo suona come un paio di classiche relazioni uno-a-molti. Non hai indicato quale sia la cosa che stanno commentando e / o favorendo quindi chiamerò semplicemente "Post" qui. È l'entità radice del tuo Entity-Relationship-Model (ERM) ... noto anche come uno "schema" di database.

Considera questo schema ...

Post
- id  (PK)
- content

Comment
- id  (PK)
- post-id  (FK to Post.id)
- content

Favorite
- id  (PK)
- post-id  (FK to Post.id)
- type