Il primo è più normalizzato, anche se leggermente incompleto. Ci sono un paio di approcci che puoi adottare, il più semplice (e, a rigor di termini, il più "corretto") avrà bisogno di due tabelle, con l'ovvio vincolo FK.
commentid ---- subjectid ----- idType
--------------------------------------
1 22 post
2 26 photo
3 84 reply
4 36 post
5 22 status
idType
------
post
photo
reply
status
Se lo desideri, puoi utilizzare un char(1) o simile per ridurre l'impatto di varchar sulla lunghezza della chiave/indice o per facilitare l'uso con un ORM se prevedi di utilizzarne uno. I NULL sono sempre un fastidio e se inizi a vederli comparire nel tuo design, starai meglio se riesci a trovare un modo conveniente per eliminarli.
Il secondo approccio è quello che preferisco quando ho a che fare con più di 100 milioni di righe:
commentid ---- subjectid
------------------------
1 22
2 26
3 84
4 36
5 22
postIds ---- subjectid
----------------------
1 22
4 36
photoIds ---- subjectid
-----------------------
2 26
replyIds ---- subjectid
-----------------------
3 84
statusIds ---- subjectid
------------------------
5 22
C'è ovviamente anche l'approccio ibrido (leggermente denormalizzato), che uso ampiamente con set di dati di grandi dimensioni, poiché tendono ad essere sporchi. Fornisci semplicemente le tabelle di specializzazione per gli idType predefiniti, ma mantieni una colonna idType ad hoc nella tabella commentId.
Si noti che anche l'approccio ibrido richiede solo 2 volte lo spazio della tabella denormalizzata; e fornisce una banale restrizione delle query per idType. Il vincolo di integrità tuttavia non è semplice, essendo un vincolo FK su un'UNION derivata delle tabelle dei tipi. Il mio approccio generale consiste nell'utilizzare un trigger sulla tabella ibrida o una vista aggiornabile equivalente per propagare gli aggiornamenti alla tabella del sottotipo corretto.
Sia l'approccio semplice che il più complesso approccio sottotipo tabellare funzionano; tuttavia, per la maggior parte degli scopi si applica KISS, quindi sospetto che probabilmente dovresti semplicemente introdurre una tabella ID_TYPES, l'FK pertinente, e farla finita.
