Le premier est plus normalisé, quoique légèrement incomplet. Vous pouvez adopter plusieurs approches, la plus simple (et à proprement parler, la plus "correcte") nécessitera deux tables, avec la contrainte FK évidente.
commentid ---- subjectid ----- idType
--------------------------------------
1 22 post
2 26 photo
3 84 reply
4 36 post
5 22 status
idType
------
post
photo
reply
status
Si vous le souhaitez, vous pouvez utiliser un char(1) ou similaire pour réduire l'impact du varchar sur la longueur de la clé/index, ou pour faciliter l'utilisation avec un ORM si vous prévoyez d'en utiliser un. Les valeurs NULL sont toujours un problème, et si vous commencez à les voir apparaître dans votre conception, vous serez mieux si vous pouvez trouver un moyen pratique de les éliminer.
La deuxième approche est celle que je préfère lorsqu'il s'agit de traiter plus de 100 millions de lignes :
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
Il y a bien sûr aussi l'approche hybride (légèrement dénormalisée), que j'utilise beaucoup avec de grands ensembles de données, car ils ont tendance à être sales. Fournissez simplement les tables de spécialisation pour les idTypes prédéfinis, mais conservez une colonne idType ad hoc sur la table commentId.
Notez que même l'approche hybride ne nécessite que 2x l'espace de la table dénormalisée ; et fournit une restriction triviale des requêtes par idType. La contrainte d'intégrité n'est cependant pas simple, étant une contrainte FK sur une UNION dérivée des tables de types. Mon approche générale consiste à utiliser un déclencheur sur la table hybride ou une vue actualisable équivalente pour propager les mises à jour vers la table de sous-type correcte.
L'approche simple et l'approche plus complexe du tableau de sous-types fonctionnent ; Pourtant, dans la plupart des cas, KISS s'applique, donc je suppose que vous devriez probablement simplement introduire une table ID_TYPES, le FK pertinent, et en finir avec.
