O primeiro é mais normalizado, embora um pouco incompleto. Existem algumas abordagens que você pode adotar, a mais simples (e estritamente falando, a mais 'correta') precisará de duas tabelas, com a óbvia restrição 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 desejar, você pode usar um char(1) ou similar para reduzir o impacto do varchar no comprimento da chave/índice, ou para facilitar o uso com um ORM se você planeja usar um. NULLs são sempre um incômodo, e se você começar a vê-los aparecer em seu design, será melhor descobrir uma maneira conveniente de eliminá-los.
A segunda abordagem é a que eu prefiro ao lidar com mais de 100 milhões de linhas:
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
É claro que também existe a abordagem híbrida (ligeiramente desnormalizada), que uso extensivamente com grandes conjuntos de dados, pois eles tendem a ser sujos. Basta fornecer as tabelas de especialização para os idTypes predefinidos, mas manter uma coluna adhoc idType na tabela commentId.
Observe que mesmo a abordagem híbrida requer apenas 2x o espaço da tabela desnormalizada; e fornece restrição de consulta trivial por idType. A restrição de integridade, no entanto, não é direta, sendo uma restrição FK em um UNION derivado das tabelas de tipos. Minha abordagem geral é usar um gatilho na tabela híbrida ou em uma visualização atualizável equivalente para propagar atualizações para a tabela de subtipo correta.
Tanto a abordagem simples quanto a abordagem de tabela de subtipos mais complexa funcionam; ainda assim, para a maioria dos propósitos, o KISS se aplica, então apenas suspeito que você provavelmente deveria apenas introduzir uma tabela ID_TYPES, o FK relevante, e terminar com isso.
