První je více normalizovaný, i když mírně neúplný. Existuje několik přístupů, které můžete použít, ten nejjednodušší (a přísně vzato ten „nejsprávnější“) bude potřebovat dvě tabulky se zřejmým omezením FK.
commentid ---- subjectid ----- idType
--------------------------------------
1 22 post
2 26 photo
3 84 reply
4 36 post
5 22 status
idType
------
post
photo
reply
status
Pokud chcete, můžete použít znak char(1) nebo podobný ke snížení dopadu varchar na délku klíče/indexu nebo k usnadnění použití s ORM, pokud jej plánujete používat. NULL jsou vždy obtěžující, a pokud je začnete vidět ve vašem návrhu, budete na tom lépe, když najdete pohodlný způsob, jak je odstranit.
Druhý přístup preferuji při práci s více než 100 miliony řádků:
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
Existuje samozřejmě také (mírně denormalizovaný) hybridní přístup, který hojně používám u velkých souborů dat, protože mají tendenci být špinavé. Jednoduše poskytněte tabulky specializací pro předdefinované idTypes, ale ponechte adhoc sloupec idType v tabulce commentId.
Všimněte si, že i hybridní přístup vyžaduje pouze 2x větší prostor než denormalizovaná tabulka; a poskytuje triviální omezení dotazů pomocí idType. Omezení integrity však není přímočaré, protože jde o omezení FK na odvozené UNION z typových tabulek. Mým obecným přístupem je použít spouštěč buď na hybridní tabulce, nebo na ekvivalentním aktualizovatelném zobrazení k šíření aktualizací do správné tabulky podtypů.
Funguje jak jednoduchý přístup, tak složitější přístup k tabulce podtypu; stále platí, že pro většinu účelů platí KISS, takže mám podezření, že byste pravděpodobně měli zavést tabulku ID_TYPES, relevantní FK, a skončit s tím.