Jedna zbiorcza tabela czy kilka?, dla komentarzy Opcje

[deha21]

Lepszym wyjściem jest stworzenie jednej zbiorczej tabeli dla systemu komentarzy czy rozbicie jej na kilka? Komentarze pochodziłyby z newsów, artykułów, galerii zdjęć itd. Czy może stworzyć osobną tabelę dla każdego działu, np. 'komentarze_newsy', 'komentarze_artykuly' itd.

[Crozin]

Raczej kilka.
1. Każdy rodzaj komentarza ma odwołanie (klucz obcy) do innej, specyficznej dla swojego typu tabeli.
2. Nawet jeżeli początkowo wszystkie komentarze są dokładnie taką samą strukturą (z pominięciem klucza obcego z pkt. #1) nie oznacza to, że w przyszłości będą.
3. Nawet w ramach jednakowej struktury mogą istnieć inne "parametry" co do samych danych dla różnych komentarzy.

[deha21]

Ok, czyli tak jak zrobiłem za pierwszym razem.
Jeszcze mam drugie małe pytanie (nie chce zakładać nowego tematu). Potrzebuję przetrzymać w bazie wstęp do artykułu (max 200 znaków) - co lepsze VARCHAR czy TINYTEXT?

[Crozin]

Niby VARCHAR ma wystarczającą pojemność (do 255 znaków), ale pewnie w takim opisie może znaleźć się do 200 widocznych znaków, a nie znaków w ogóle - ma tu na myśli przykładowo elementy HTML-a takie jak odnośniki, paragrafy czy jakieś cytaty. Co więcej raczej wątpię byś miał potrzebę zakładania indeksu na taką kolumnę, tak więc raczej sugerowałbym kolumnę typu TEXT - wygenerują one takie samo obciążenie, a wydają się trafniejszym wyborem dla tego typu kolumny.

[phpion]

Ja byłbym za 1 tabelą zbiorczą. Nie założysz na takiej tabeli więzów integralności, ale za to "podpięcie" komentarzy do kolejnego elementu (produkty w sklepie, filmiki, konta użytkowników - cokolwiek) zrobisz pstryknięciem palca. Co do uwag Crozina:

1. Każdy rodzaj komentarza ma odwołanie (klucz obcy) do innej, specyficznej dla swojego typu tabeli.

Fakt, ale można zapisać object_id (ID rekordu, którego tyczy komentarz) oraz object_type (np. 1 newsy, 2 zdjęcia itd).

2. Nawet jeżeli początkowo wszystkie komentarze są dokładnie taką samą strukturą (z pominięciem klucza obcego z pkt. #1) nie oznacza to, że w przyszłości będą.

Teoretyzowanie

3. Nawet w ramach jednakowej struktury mogą istnieć inne "parametry" co do samych danych dla różnych komentarzy.

Nie ma co w tym przypadku aż tak wybiegać w przyszłość. Komentarze to komentarze - treść. W przypadku konieczności dodania dodatkowych parametrów można wówczas utworzyć tabelę uzupełniającą parametry dla konkretnego typu komentarzy. Jednak jakie jest prawdopodobieństwo, że komentarze będzie trzeba rozbudować o jakieś parametry? Wg mnie małe.

Moim zdaniem 1 tabela ma sporo plusów:
- komentarze masz w 1 miejscu (rozbudowa ich o dodatkową kolumnę to modyfikacja 1 tabeli),
- dodanie komentarzy do kolejnego elementu systemu jest dziecinnie proste,
- prędkość wyszukiwania komentarzy dla konkretnego elementu (object_id + object_type) jest bardzo zbliżona do zwykłego (object_id).

Ostatnio zastosowałem podobne podejście w jednym z portali. Dotyczyło jednak tagów. Nie robiłem tabel photo_tags, article_tags itd. tylko 1 object_tags. Dodanie tagowania np. profilu użytkownika to dosłownie chwila pracy. Podejście to sprawdza się znakomicie. Trzeba tylko pamiętać, że przy usuwaniu danego rekordu należy ręcznie usunąć powiązane z nim tagi (brak klucza obcego ON DELETE CASCADE).

[Crozin]

@phpion: Prawdę powiedziawszy oba rozwiązania mają drobne plusy i minusy względem siebie.

Dodanie komentarzy do nowego elementu? W obu przypadkach to dosłownie chwila roboty. W jednym robisz niemal bezmyślne copy-n-paste w drugim dodajesz nowy wariant dla kolumny z typem. Obie procedury powtarzasz po stronie bazy danych i aplikacji.
Dodanie nowego elementu do każdego rodzaju aplikacji? Tutaj rzeczywiście na pierwszy rzut oka jedna tabela to mniej roboty, ale... ale zapewne będzie korzystać z jakiegoś ORM-a, a te oferują dziedziczenie, więc wspólne cechy wszystkich komentarzy wydzieli sobie do jednego elementu, a resztę załatwi automat. Swoją drogą nawet niektóre bazy danych oferują dziedziczenie, ale tego raczej bym tutaj nie polecał. A jak już przy ORM-ach i innych "zewnętrznych" narzędziach jesteśmy to warto zaznaczyć, że co prawda poradzą sobie one w obu przypadkach, ale pierwszy sposób jest jednak znacznie łatwiejszy w użyciu.
Więzły integralności? W obu przypadkach da się je całkiem łatwo załatwić. W pierwszym nawet nie trzeba o tym wspominać, w drugim wystarczy dodać wyzwalacze dla każdej z komentowanej tabeli by po usunięciu elementu usunąć również powiązane z nim komentarze.
Prędkość wyszukiwania jak już sam zauważyłeś będzie bardzo zbliżona w obu przypadkach.

Podsumowując, wg mnie największą zaletą - i raczej każdy się tutaj zgodzi - pierwszego rozwiązania jest bardziej naturalna realizacja relacji obiekt-komentarze, która wykorzystuje podstawowe mechanizmy relacyjnych baz danych, których to zaś wykorzystanie umożliwia lepszą współpracę z różnego rodzaju trzecim-oprogramowaniem. A ewentualne wady tego podejścia - i tutaj już się nie każdy musi zgadzać - są raczej nieistotne i łatwo eliminuje się je w normalnym projekcie.

[by_ikar]

Odniosę się jedynie do tego fragmentu:

dodanie komentarzy do kolejnego elementu systemu jest dziecinnie proste

Wydaje mi się że to nie ma znaczenia czy do jednej tabeli, czy do kilku są zapisywane komentarze. Musisz tak czy siak podać jaki argument, który będzie "kategorią" zapisu tych komentarzy, czyli sama obsługa tych komentarzy jest transparentna, czyli tym samym obsługa w każdym przypadku (jednej lub wielu tabel) jest taka sama. Dodanie komentarzy w każdym przypadku powinno być takie samo. Tak samo jest chociażby z sesjami, cache, bazami danych etc.

Moim zdaniem, minus przechowywania komentarzy w wielu tabelach, to sytuacja kiedy użyszkodnikowi udostępniamy przeszukiwanie tych komentarzy. W przypadku kilku osobnych tabel, może to nie stanowić aż tak wielkiego problemu, ale w przypadku dość rozbudowanego systemu komentarzy (komentarze gdzie popadnie; newsy, arty, profile usera, galerię, pojedyncze zdjęcia, wpisy blogowe, i tym podobne) takie przeszukiwanie może być dość problematyczne. Z racji że chyba jeszcze nawet takiej opcji na żadnej mi znanej stronie nie widziałem, to wydaje mi się że taki mankament, to w sumie żaden mankament, tylko czyste teoretyzowanie

Oba rozwiązania są dobre, i moim zdaniem wybór zależy już od naszych przyzwyczajeń czy upodobań.

[gothye]

Ja bym zastosował inne rozwiązanie :

np 4 bazy comments_0 , comments_1 , comments_2 , comments_3

w każdej z nich tabele :

news
artykuły

pobieranie oraz dodawanie do baz wykonywane byłoby po modulo id (artykułu , news)
np dla news :

czyli comments_( 4 % id_news)

[Crozin]

@gothye: Co to niby miałoby być? Sposób na zarżnięcie jakiejkolwiek pracy związanej z aplikacją czy zwykła nieznajomość mechanizmów partycjonowania baz danych?

[phpion]

@gothye:
Jedno pytanko: po co tak kombinować i utrudniać sobie życie?

[deha21]

Tworzyć 4 bazy pod każdy typ komentarzy? Eee chyba niezbyt optymalne wyjście
Ja generalnie jestem za tym, że by zrobić jedną tabelę dla wszystkich komentarzy. Ich budowa na pewno się nie zmieni, a nawet gdyby to dam sobie radę. Zaletą jest dla mnie na pewno przejrzystość informacji i wygodniejsze wyszukiwanie ich, oraz to, że łatwiej będzie w przyszłości dodać je do kolejnego modułu.