Struktura tabel forum, Które z rozwiązań jest wydajniejsze Opcje

[Athlan]

Witam.

Jestem w trakcie pisania nowego forum do projektu, kiedy przyszedł mi do głowy jeden pomysł: aby trzymać tematy i posty w jednej tabeli, a właściwie pozbyć się konstrukcji ramowej powszechnie znanego rozwiązania jakim jest trzymanie postów i ram tematów w osobnej tabeli.

Tabela miałaby mniej więcej taką budowę:

[SQL] pobierz, plaintext 
CREATE TABLE  `cms_forum` (
 `post_id` INT( 11 ) NOT NULL AUTO_INCREMENT PRIMARY KEY ,
 `post_parent` INT( 11 ) NULL ,
 `post_title` TEXT NOT NULL ,
 `post_text` TEXT NOT NULL ,
 `post_date` DATETIME NOT NULL ,
 `post_user` INT( 11 ) NOT NULL
) ENGINE = MYISAM ;
[SQL] pobierz, plaintext 

Doszukałem się kilku zalet i wad:

+ łatwa implementacja, szybkie usuwanie tematów, bez sprawdzania, czy ten nie jest czasem pierwszym (temat)
- odejście od sprawdzonego już, szybkiego i optymalnego rozwiązania - wolny listing tematów
- nagromadzenie dodatkowych pól, których nie przedstawiłem w powyższej strukturze, czyli post_status_locked, post_status_sticked itd, co spowoduje nagromadzenie danych, choćby zero jedynkowych.

Prosiłbym o opinie i podzielenie się doświadczeniami w projektowaniu fór.

[wookieb]

czy ten nie jest czasem pierwszym (temat)

A po co takie sprawdzanie?

Ja mam standardowo, mniej wiecej tak

Kod

id (int)
topic_name (varchar)
last_post (int)
...

Dzięki zachowywania id_ostatniego_postu w bardzo latwy i szybki sposob moge go wyciagnac i przedstawic w listingu.

Jezeli chodzi o kategorie to polecam drzewo left right. Jednym latwym i szybkim zapytaniem wyciagniesz ostatni post, ostatni temat z wszystkich podkategorii itd.

Rozdzielenie tabel na takie czesci jest bardzo wydajne wiec nie widze naprawde dobrego powodu dla ktorego warto od nich odchodzić.

[Spawnm]

struktura bazy wydaje się być fajna dla mniejszych projektów ,trochę więcej miejsca pewnie zajmie ale imho warto spróbować . Ale dał bym jeszcze post_user_id, post_user_ip

[Athlan]

Ostatecznie wybrałem konstrukcję ramową, standardową. Argument Spawnm'a mnie całkowicie przekonuje - to można zaimplementować w małych projektach.

Ale i tak czuję, że wynalazek postów i tematów w jednej tabeli jest dość dobry. Na podobnej zasadzie działają drzewa kategorii w Wordpressie (parent). Ale w tym miejscu zdaję sobię sprawę, że forum o coś cięższego niż drzewo kategorii... na pewno troszkę więcej danych.

[Elf]

Niekoniecznie będzie cięższa. Jeśli wydzielisz bloby (np. pola TEXT) do osobnej tabeli, a zostawisz metadane to powinno całkiem nieźle się skalować.

Ten post edytował Elf 26.06.2009, 22:57:11

[omeck]

Taki może mały offtop, ale póki to jeszcze możliwe i uzywasz MySQL to proponuję projektowanie struktury bazy na silniku InnoDb zamiast MyISAM. Całkiem niedawno musiałem robić forum dla pewnego serwisu społecznościowego i niestety musiałem bazować na starej strukturze, która działała na myisam - po prostu koszmar, podczas programowania powstaje tyle róznych możliwości straty integralności danych, że można się poszlastać :-/

[Crozin]

A jakie widzisz wady w rozwiązaniu opartym na dwóch tabelach, jednej z wątkami, drugie z postami? Bo wynajdujesz koło od nowa, czyli masz zapewne jakieś powody?

+ łatwa implementacja

Mi się wydaje, że implementacja będzie wręcz trudniejsza. Ot sprawdzanie ilości postów w wątku? COUNT()? Przechowywanie tej liczby przy każdym poście? Nie... to nie wypali

szybkie usuwanie tematów

[SQL] pobierz, plaintext 
DELETE FROM abc WHERE id = 123;
[SQL] pobierz, plaintext 

Cała reszta może zostać usunięta na drodze kluczy obcych.