Pierwszy jest bardziej znormalizowany, choć nieco niekompletny. Istnieje kilka podejść, które możesz zastosować, najprostsze (i ściśle mówiąc, najbardziej „poprawne”) będą wymagały dwóch tabel z oczywistym ograniczeniem FK.
commentid ---- subjectid ----- idType
--------------------------------------
1 22 post
2 26 photo
3 84 reply
4 36 post
5 22 status
idType
------
post
photo
reply
status
Jeśli chcesz, możesz użyć char(1) lub podobnego, aby zmniejszyć wpływ zmiennej varchar na długość klucza/indeksu lub ułatwić korzystanie z ORM, jeśli planujesz go używać. Zerowe wartości są zawsze kłopotliwe, a jeśli zaczniesz je pojawiać się w twoim projekcie, lepiej będzie, jeśli znajdziesz wygodny sposób ich wyeliminowania.
Drugie podejście preferuję w przypadku ponad 100 milionów wierszy:
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
Istnieje oczywiście również (nieco zdenormalizowane) podejście hybrydowe, które intensywnie wykorzystuję w przypadku dużych zbiorów danych, ponieważ są one zwykle brudne. Po prostu podaj tabele specjalizacji dla wstępnie zdefiniowanych idTypes, ale zachowaj adhoc kolumnę idType w tabeli commentId.
Zauważ, że nawet podejście hybrydowe wymaga tylko 2x przestrzeni zdenormalizowanej tabeli; i zapewnia trywialne ograniczenie zapytań według idType. Jednak ograniczenie integralności nie jest proste, ponieważ jest ograniczeniem FK na pochodnej UNION tabel typów. Moje ogólne podejście polega na użyciu wyzwalacza w tabeli hybrydowej lub równoważnego aktualizowanego widoku w celu propagowania aktualizacji do właściwego podtypu tabeli.
Działa zarówno proste podejście, jak i bardziej złożone podejście oparte na tabeli podtypów; mimo to, do większości celów stosuje się KISS, więc podejrzewam, że prawdopodobnie powinieneś po prostu wprowadzić tabelę ID_TYPES, odpowiedni FK i skończyć z tym.
