Qualunque sia la soluzione migliore dipende IMHO su più di un semplice tavolo, ma anche come questo viene utilizzato altrove nell'applicazione.
Supponendo che i commenti siano tutti associati ad altri oggetti, diciamo che estrai tutti i commenti da quell'oggetto. Nella progettazione proposta, l'estrazione di tutti i commenti richiede la selezione da una sola tabella, che è efficiente. Ma questo sta estraendo i commenti senza estrarre le informazioni sul poster di ogni commento. Forse non vuoi mostrarlo, o forse sono già memorizzati nella memoria.
E se fosse necessario recuperare le informazioni sul poster durante il recupero dei commenti? Quindi devi unirti a due diverse tabelle, e ora il set di record risultante viene inquinato con molti valori NULL (per un commento del profilo, tutti i campi utente saranno NULL). Il codice che deve analizzare questo set di risultati potrebbe anche diventare più complesso.
Personalmente, avrei probabilmente iniziare con la versione completamente normalizzata, e poi denormalizzare quando inizio a vedere i problemi di prestazioni
C'è anche una soluzione completamente diversa possibile il problema, ma questo dipende dal fatto che o non rende senso nel dominio. Cosa succede se ci sono altri posti nell'applicazione in cui un utente e un poster possono essere usati in modo intercambiabile? Cosa succede se un utente è solo un tipo speciale di un profilo? Quindi penso che la soluzione dovrebbe essere risolta generalmente nelle tabelle utente/profilo.Per esempio (alcuni abbreviato pseudo-SQL):
create table AbstractProfile (ID primary key, type) -- type can be 'user' or 'profile'
create table User(ProfileID primary key references AbstractProfile , ...)
create table Profile(ProfileID primary key references AbstractProfile , ...)
allora qualsiasi posto nella propria applicazione, in cui un utente o un profilo possono essere usati in modo intercambiabile, è possibile fare riferimento al LoginID.
+ 1 per la tecnica correttamente normalizzata – DancesWithBamboo
Mi piace questa soluzione ma fare un semplice filtraggio dei commenti per tipo di commentatore o commentatore richiederebbe un join. – cherouvim
Effettivamente - ma un join è un piccolo inconveniente, ed è sempre possibile creare una vista o una stored procedure per questo in modo da non dover pensare al join ogni volta che è necessario ottenere quei dati. – becquerel