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.

A po co takie sprawdzanie?

Ja mam standardowo, mniej wiecej tak

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ć.

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

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.

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ć.

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ć :-/

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?
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

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

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