De eerste is meer genormaliseerd, zij het enigszins onvolledig. Er zijn een aantal benaderingen die u kunt volgen, de eenvoudigste (en strikt genomen de meest 'juiste') heeft twee tabellen nodig, met de voor de hand liggende FK-beperking.
commentid ---- subjectid ----- idType
--------------------------------------
1 22 post
2 26 photo
3 84 reply
4 36 post
5 22 status
idType
------
post
photo
reply
status
Als je wilt, kun je een char(1) of iets dergelijks gebruiken om de impact van de varchar op de sleutel-/indexlengte te verminderen, of om het gebruik met een ORM te vergemakkelijken als je van plan bent er een te gebruiken. NULL's zijn altijd lastig, en als je ze in je ontwerp ziet verschijnen, ben je beter af als je een handige manier kunt bedenken om ze te elimineren.
De tweede benadering is er een waar ik de voorkeur aan geef als ik te maken heb met meer dan 100 miljoen rijen:
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
Er is natuurlijk ook de (enigszins gedenormaliseerde) hybride benadering, die ik veel gebruik bij grote datasets, omdat ze vaak vies zijn. Geef gewoon de specialisatietabellen voor de vooraf gedefinieerde idTypes, maar houd een adhoc-kolom idType in de commentId-tabel.
Merk op dat zelfs de hybride benadering slechts 2x de ruimte van de gedenormaliseerde tabel vereist; en biedt triviale querybeperking door idType. De integriteitsbeperking is echter niet eenvoudig, omdat het een FK-beperking is op een afgeleide UNION van de typetabellen. Mijn algemene benadering is om een trigger te gebruiken op de hybride tabel, of een equivalente updatebare weergave om updates door te geven aan de juiste subtypetabel.
Zowel de eenvoudige benadering als de meer complexe subtypetabelbenadering werken; toch is KISS voor de meeste doeleinden van toepassing, dus ik vermoed dat je waarschijnlijk gewoon een ID_TYPES-tabel moet introduceren, de relevante FK, en daarmee klaar bent.