Witam,

Potrzebuje waszego wsparcia w sformulowaniu zalozen projektu o nazwie " Forum internetowe zoptymalizowane pod duza ilosc wpisow".

Po wstepnej wymianie maili ( z zalozeniami pracy ) z moim promotorem wyszlo ze albo moj sposob myslenia jest zly i czegos nie rozumiem , albo on nie wie co pisze ;-).

Dlatego tez prosilbym was o pomoc w tej materii, bo grudzien juz za 3 miechy obrona a ja nie zaczalem jeszcze ;-).

Ze wstepnej rozmowy wynika ze system ma dzialac w miare niezaleznie od bazy danych wiec mysle o uzyciu adodb.

dalej chcialem zeby forum standardowo pobieralo posty z tygodnia takie rozwiazanie jest bodajrze w vbulletin.

Mysle tez zeby starac sie ograniczyc z iloscia zapytan sql do 5 lub mniej na strone ( jesli sie da ).

myslalem tez zeby wszystkie dane pobierac w ORDER BY DESC oraz zeby nie wykorzystywac zapytan pytu SELECT COUNT tylko pobierac dane z odpowiednich pol opisu danych forow ( np. ilosc tematow itp ).

ale do tych postulatow odniosl sie cokolwiek dziwnie...

bylbym wdzieczny za wszelkie sugestie, forum nie musi miec systemu templatow i bajerow. ma dzialac tylko sprawnie , stabilinie i szybko, przy duzym obciazeniu.

Bede wdzieczny za wszelkie sugesitie.
pozdrawiam

"Ze wstepnej rozmowy wynika ze system ma dzialac w miare niezaleznie od bazy danych wiec mysle o uzyciu adodb"

Samo AdoDB ci tego nie zapewni. Musisz pamiętać że składnia SQL dla różnych baz jest odmienna. Dlatego pamiętaj by zgromadzić w jednym miejscu wszelkie zapytania. Wtedy tworzysz taki plik dla różnych wersji baz, a adodb służy tylko do uwpólnienia procesu łączenia się z bazą i wysyłania zapytań.

zapewni jesli bedzies sie trzymal odpowiedniej skladni, a nie wrzucal do query zapytania jak lecą

Tylko, ze niektore rzeczy nie maja uniwersalnej skladni.
Wezmy np. przeszukiwanie typu Full-text Search. Jak chcesz to zapisac tak, zeby dzialalo na roznych RDBMS ?
IPB stosuje w tym celu cos podobnego jak podal Vengeance. Maja swoja klase do budowania zapytan i wszystkie proste zapytania sa przez nia generowane odpowiednio pod zainstalowana baze. A zapytania, ktore moga wymagac rzeczy specyficznych dla danej bazy sa trzymane w osobnym pliku.

ano pomysl z klasa do budowania zapytan nie jest taki zly. jesli to dobrze zrobic bedzie to ciekawe rozwiazanie.

a co do obciazenia bazy. jesli to ma lazic na kazdej bazie, to jest problem. bo taki mysql nie ma podzapytac co by ciut pomoglo. wiec musisz jechac na podstawowej skladni sqla i wywalac spora ilosc zapytan przy kazdym zadaniu. w miare mozliwosci musisz ograniczyc ilosc zapytan i tyle, nic wiecej sie nie da.

inna rzecza jest ze jak to odpalisz na mysql to przy 300-400k wpisach na tabeli mysql umiera (z tego co kiedys testowalem czasy odpowiedzi beda w granicach 3min), posgresql jeszcze spokojnie pociagnie, a oracle pewnie tym bardziej chociaz tego ostatniego obstawiam w ciemno.

no a zeby zmniejszyc ilosc zapytan trzeba zrobic czyste forum bez bajerow. powywalac avatary, emoty i inne cuda jak ilosc ludzi na danym forum itd.

ja bym do sprawy podzszedl od innej strony. od baz danych. bo to jest slaby pkt tego problemu. nawet majac mysqla 3.x - mozna walnac ze 2-N serwerow z replikacjami bazy, a skrypty forum rownomiernie obciazaja baze. najprostrzy sposob? masz w pliku namiary na all bazy i zwyczajnie losuj - tutaj juz prawodpodobienstwo.

tyle ze nie mam zielonego pojecia jakby to wygladalo. zgaduje ze to jednak nie za dobry pomysl, bo na forum przy duzym obciazeniu co chwila cos sie zmienia i praktycznie co chcila trzeba by slac z master bazy do slavow zmiany. moze i by tu fungowalo, a moze nie. nie mam pojecia jak w przypadku forum by to wyglodalo. trzeba by testy przeprowadzic

z ta przesada ze mysql umiera przy 3 milionach rekordow to bym nie byl taki pewien.
Rozumiem ze tablica nie bedzie wygladac jak pas startowy szeroka, w pojedynczym rekodzie bedziesz mial okolo 30 kolumn.
Dobra konstrukcja potrafi naprawde wiele, ja aktualnie w mysqlu mam ponad 8 milionow rekordow z czego jedna tablica ma ich wlasnie okolo 3 milionow i nie moge powiedziec zeby stronka nam chodzila kiepsko, a wejsc mamy srednio okolo 80tys unikalnych.

To tak tylko wzgledem mysql'a

Tak rozmawiacie o bazach danych, ale nikt nie wspomniał o tym, że adodb jest wolne... Chcesz niezależność od bazy i szybkość, to zastanów się nad PDO, które jako rozszerzenie pecl zainstalujesz pod php5, a w php5.1 jest włączone do dystrybucji... Jako szablonów spokojnie możesz użyć samego php - jeżeli forum nie będzie skomplikowane to się sprawdzi...

Pamiętaj o wszelkiego rodzaju cache.

Na bazach się specjalnie nie znam, więc nie będę się włączał do dyskusji.

Może się też opłacić ewntualne cache'owanie wyników bardziej skomplikowanych zapytań z bazy do plików. Jeśli ustawisz czas życia takiego pliku na powiedzmy minute lub dwie, to forum wciąż będzie funkcjonalne, a będzie mniej zapytań.

ja wiem.... co by mialo byc cacheowane ? dla mnie jedyna rzecza jaka moze byc cacheowana to takie malo wazne rzeczy jak urodziny uzytkownikow, ich liczba i statystyki, danych tematow i postow bym sie bal ruszac bo to po prostu nie sprawdzi sie przy duzej ogladalnosci tak mi sie zdaje.
co do zapytan dzialajacych na roznych bazach danych to mysle zeby zrobic cos takiego jak w stylu phpbb jest ze masz skladnie case: i tam sobie wybiera zapytanie wzorujac sie na tym co jest zdefiniowane w configu - jesli cos nie chce dzialac od razu... w zasadzie podejrzewam ze rozwiazanie jest podobne do tego zastosowanego w IPB tylko inaczej zaimplementowane.

Najwiekszym problemem dla mnie bedzie dzialanie bazy danych przy duzej ilosci rekordow i nie wiem jak to rozwiazac, mysle ze niezlym rozwiazaniem przy bazie powyzej 500 mb ( zalozmy ) bylo by tworzenie pojednynczej tabeli dla kazdego z forow.. co o tym myslicie ? przy wiekszej ilosci oddzielnych plkow z danymi taki dysk twardy traci mniej czasu na wyszukiwanie odpowiednich danych, niz wyszukanie fragmentu jednego pliku.

Jeżeli sądzisz, że cache nic nie da to jesteś w błędzie... Akurat przy dużych stronach cache jest zbawieniem. Tak jak mówi bregovic, zamiast ciągle wysyłać zapytania do bazy można zapisywać na dysku najczęściej pobierane dane w przystępniejszej postaci.

Rozwiązanie z wieloma tabelami nie wygląda za dobrze. Cache jest lepszym pomysłem - w taki sposób znacząco odciążasz bazę danych.

odciaza owszem, ale nie w momencie kiedy dane maja sie dynamicznie zmieniac co chwile chyba, to jest dobre jak masz np. strone glowna z newsami i ci ktos dodaje newsa co godzine... przynajmniej tak mi sie wydawalo ze wtedy jest sens cacheowania.
Pozatym co sie stanie jesli jedna osoba odpowie w temacie a nastepna wejdzie sekunde pozniej i tez odpowie ? ta druga osoba nie zobaczy tego jednego posta i wtedy dany temat traci spojnosc.... jest zbyt duze prawdopodobnienstwo ze cos pojdzie nie tak przy takim podejsciu - pozatym jak rozwiazac problem uprawnien w takim przypadku ? to wszystko zmienia sie przeciez co chwile , sa rozne grupy , kazda ma inne uprawnienia do tematow i for, to wszystko trzeba brac pod uwage, pozatym nie wiem jak to by sie mialo do zajmowania miejsca na dysku przy duzej bazie i duzej ilosci osob na raz... wtedy nie jestem wcale pewien czy obciazenie nie bylo by mniejsze.

Zawsze istnieje zaleznosc
ilosc zajmowanej pamieci * szybkosc = const


Po dodaniu odpowiedzi usuwasz cache z tematem. Przy otworzeniu strony z tym tematem tworzysz cache i wyswietlasz strone. Przeciez samych obejrzen stron jest z 10 razy wiecej nioz odpowiedzi.

np.

Przyczepiony: Najlepszy według was edytor do php! | 457 | 27 129 - ok 59 razy wiecej
Forum internetowe heavy-duty | 10 | 153 - ok. 15 razy wiecej

wiec jest to oplacalne.

W momencie modyfikacji danych czyścisz fragment cache, który został zmodyfikowany i tworzysz (albo nie) je od nowa z bazy. To czy będzie się opłacało zastosować cache trzeba sprawdzić, ale skoro na forum pojawia się dużo nowych wpisów, to operacji odczytu będzie dużo więcej...

Uprawnienia nie sa problemem, bo nie musisz zachowywać całego wyjścia. Jeżeli chcesz nadawać uprawnienia do wszystkich tematów osobno (co jest według mnie bez sensu) to musisz zapisać je w cache. Dużo miejsca chyba nie poświęcisz na to...

Co z miejscem na dysku? Nad tym trzeba chwilę pomyśleć, ale można spokojnie ograniczyć zużycie wywalając najrzadziej czytane wpisy z cache a przechowując najważniejsze. Limity można ustawić na sztywno.

uprawnienia byly by dawane do grup a grupy przypisywane do gorum , taki uklad jest chyba najpopularniejszy czyli sie sprawdza.

co do miejsca na dysku to mysle ze moglbym zrobic skrypt wywolywany co np . 30 min ktory by kasowal wszystkie pliki cache - wtedy dysku nie zaleje fala cacheowanych plikow...

no ale ok : mozemy zalozyc ze jest jeden punkt w zalozeniach projektu:
Cacheowanie danych

to teraz jeszcze pytanie co zrobic w sytacji kiedy 1 uzytkownik wchodzi na strone glowna i ma np uprawnienia tak ustawione ze widzi 10 for ,a drugi widzi tylko 5, trzeba by oddzielny cache dla kazdego id usera robic ( mzoe plote glupoty ale nie robilem nigdy cacheowania sql wiec sie nie orientuje za dobrze - czytalem tylko ze nie sprawdza sie to w stronach gdzie czesto dynamicznie sie zmieniaja dane ), nie wiem czy w takiej sytacji cacheowanie nie bierze w leb przynajmniej w widokach spisu forow ?

Nie wiem czy cache przy wyświetlaniu listy for się przyda, chociaż to zawsze kilka zapytań mniej. Możesz utworzyć obiekt-kontener wszystkich for i trzymać dla każdego forum listę wymaganych ról od razu w cache. Uprawnienia użytkownika trzymasz w sesji.

Oczywiście nie możesz trzymać w cache danych osobistych użytkownika, bo wtedy każdy miałby swoje cache, a nie o to chodzi. Częściej potrzebne dane konkretnego użytkownika trzymasz w sesji.

Masz dwie możliwości. Albo zapisujesz całe wyniki z bazy w tablicy - a działania logiczne robisz już w php. Albo robisz różne cache dla różnych grup. Osobbiście wolałbym opcję pierwszą...

no dobrze jeszcze bym chcial by ktos sie do tego cacheowania ustosunkowal z uzytkownikow, ale jeden punkt mamy , macie jeszcze jakies pomysly na optymalizacje tego wszystkiego ? (ja myslalem o takich sprawach jak InnoDB z mysql ale to bylo przed tym jak sie okazalo ze system ma pracowac na roznych typach baz :/ ) bo na prace inzynierska to chyba troche malo chociaz implementacja tego mechanizmu chyba nie bedzie taka prosta :/ a ja z php tak srednio stoje ( nie pytac czemu sobie taki temat wzialem )

Jeżeli masz zająć się również optymalizacją oprogramowania serwera, to na pewno musisz przemyśleć wewnętrzne cache php. Cache kodu pośredniego przy dużej liczbie wywołań skryptu jest jedną z najlepszych optymalizacji. Unikasz parsowania kodu za każdym razem, zamiast tego trzymasz już kod maszyny zenda w pamięci. Poszukaj czegoś googlarką "php cache".

Tak czy innaczej najważniejszy będzie dobry projekt. Optymalizacje zawsze można przeprowadzić, ale złego projektu nie poprawisz. Więc najpierw pożądnie pomyśl nad strukturą bazy, budową samego skryptu, a potem weź się za przyspieszanie.

nie od strony serwera , nic nie mam robic, sam program... tylko zastanawia mnie jedna rzecz, ze np. ani IPB, ani Vbulletin ani phpBB nie uzywa rozbudowanego cacheowania sql ( o ile w ogole uzywa - w moim forum phpBB raptem 1 zapytanie jest chachowane wynik sql )
mysle ze gdyby to sie sprawdzalo w aplikacj tego typu to by dawno to bylo zaimplementowane, ale moze sie myle...

Bo generalnie cacheowanie sql nie jest potrzebne - sam zażuciłeś że ma być heavy-duty. Ztymże jak ma być na prawdę heavy-duty, to IMO trzeba optymalizować serwer i pisać pod konkretną bazę danych, wykorzystywać max możliwości. Połączenie kompatybilności i heavy-duty to bardzo trudna sprawa.

eh generalnie temat pracy brzmi tak jak w pierwszym poscie "forum dyskusyjne zoptymalizowane pod duza ilosc wpisow", i ma dzialac nie tylko pod jednym rodzajem baz danych... nie moj wymysl tylko promotora, daltego wlasnie kombinuje z takimi sprawami jak kazde forum w oddzielnej tabeli itp...


totez sam sie zastanawiam co wlasciwie ja mam zrobic
chciaz do smiechu mi nie jest bo czasu coraz mniej a ja nie mgoe zaczac nawet :/

Sh4dow a jaka wersje mysqla macie ze daje rade z 3 mln na pojedynczej tabeli?
jak mozesz wez walnij tam proste zapytanie z wherem, a pozniej ze 2 bardziej zlozone i podaj mi czasy odpowiedzi.

a wracajac do tematu. cachowanie moze sie przydac, ale trzeba cachowac pierdly. nie ma sensu cachowac tematow itd. - bo po 1) watpie zebysmy odciazyli baze - i tak co chwile bedziemy wysyac zapytania zebyc cachowac wyniki. 2) jak bedziemy caly czas zachowac zasisniemy dysk, bo zakladam ze to zwykly dysk 7200 a nie jakies monstrum typowo serwerowe - chociaz oczywiscie wszystko zalezy co oznacza termin "duza ilosc uzytkownikow".

mozna sie tez pobawiac w cache po stronie phpa i roznego rodzaju accelatory.

w sumie rownie glupimy pomyslem byloby umieszczenie kazdego forum na osbnym serwie BD. no ale tutaj trzeba by napisac jakis w miare inteligenty algorytm, ktory by z poziomu www pozwalal dodawac kolejne serwer i przenosilby tabele na tak dodany serwer. generalnie mozna rozproszyc baze. tylko beda jaja jak padnie 1 z serwerow. dlatego nie jestem specjalnym zwolennikiem czystego rozproszenia BD.

mimo wszystko ja bym kombinowal nad jakis progsem do inteligentnego i latwego zarzadzania srodowiskiem serwerow BD. polaczylm rozproszenie z replikacjami. fakt ze w sporo serwow by trzeba bylo ale trudno no ale to by rozwiazywalo problem. bo jesli cos za wolno chodzi - to wina bazy. dodajemy 2 serwery -> 1 przejmuje czesc tabel a drugi jest jego kopia bezpieczenstwa. i tak w kolko.

p.s
powiedz promotorowi zeby Ci dal caly kluster

buahahah ... albo 2 od razu

rozmawialem dzisiaj z promotorem , i rozmowa byla bardziej konstruktywna, przede wszystkim forum ma miec ogromniasta liste postow ( czytaj nie wiem ile to jest ale duzo ;P )

i czesc rzeczy mozna trzymac w cache-u, ale dobrym pomyslem jest trzymanie oddzielnych for w oddzielnych tabelach ( ma to swoje wady oczywiscie i nie jest jakies super eleganckie, ale... ) , baza tworzy oddzielny plik dla kazdej tabeli wiec czasu wyszukania oddzielnych rekordow beda mniejsze niz by mialo skanowac jeden ogromny plik ( nie zaglebiamy sie w takie problemy jak wyszukiwarka itp ... ) na 100% przyspieszy to dzialanie .

Kolejny pomysl to rotowanie forow do jakichs tabel archiwizacyjnych zeby user na zadanie mogl uzyskac dostep do tych danych a reszta normalnie , ale nie wiem jeszcze w jaki sposob to by mialo byc rozwiazane jeszcze.

takze bardziej to beda tricki zwiazane z serwerem baz danych niz z php i optymalizacja aplikacji samej w sobie , najbardziej waskim gardlem bedzie chyba baza i na tym sie trzeba skupic.

( temat i tak jest teoretyczny scisle i nie bedzie tam testu na 10000 uzytkownikow i obciazenia 300 osob online - liczy sie ilosc wpisow w bazie )

Tabela dla każdego forum to poroniony pomysł, sprzeczny z zasadami optymalnego tworzenia baz danych.

Mówisz że ma wady. Oczywiści że ma wady. A jakie ma wg. Ciebie zalety?

"czytaj nie wiem ile to jest ale duzo ;P"

Patrząc na tak popularne fora jak phpBB.com i wiele innych tego typu z ogromną ilością postów, chyba nie istnieje takie które mogło by zagrozić stabilności MySQL.

Tak więc dowiedz się dokładniej co on uwarza za "dużo", bo wg mnie to "dużo" jest nierealnie duże i niedoosiągnięcia ;p

3 miliony rekordow w tabeli MySQL to zadne wyzwanie w mojej opinii.

Jw. tworzenie osobnych tabel dla postwo czy poszczegolnych for to poroniony pomysl.

dlaczego poroniony pomysl ? wiem ze wyszukiwanie bedzie mocno ograniczone w dzialaniu itp... ale ten poroniony pomysl ma podstawy w funkcjonowaniu dyskow twardych:

- seek time danych na dysku z tego co mi sie wydaje powinien byc mniejszy w momencie kiedy mamy do czyniena z mniejszymi plikami niz z wiekszymi ( a kazda tabela to przeciez osobny plik ) wiec bedzie wiecej mniejszych plikow z poszczegolnymi tabelami dla kazdego forum niz jedna ogromna tabela posts dla przykladu - ale to moja teoria.

moze wy macie jakies pomysly w sposobie optymalizacji tego ? nie martwcie sie tym ze wyszukiwanie nie bedzie dzialac tak jak na popularnych forach itp. to nie jest akurat tutaj najwazniejsze.

Forum jako takie ma byc jak najlzejsze dla serwera... takie jest zalozenie - to wszystko prawdopodobnie wyjdzie dopiero w benchmarkach dlatego kazda duperele musze wziasc pod uwage

Zasada XP: nie zgaduj -- zmierz.
Zrob wg. jednej z koncepcji -- potem dodaj tabele dla kazdego z forum i poprzenos tematy i sprawdz wydajnosc.

http://www.webhostingtalk.com/

Zwykly nietuningowany vBulletin



Proponuje nie kombinowac tylko porzadnie przemyslec strukture baze, ustawic odpowiednie indeksy a takze zadbac o mechanizm cache.

Z tego co wiem jesli baza spelnia te warunku to skrypt bedzie zasuwal nawet jak bedzie 10 mln postow. Sa odnotowane wyniki kiedy MySQL mial w tabeli 5 MILIARDOW rekordow.

w sumie zgadzam sie w 100% tylko ze 1 : na domowym kompie moge miec problemy z odczuwalna roznica - ale to sie zmierzy
2: ( co mnie bardziej martwi ) za pozno sie za to wziaem i boje sie ze jak popelnie zbyt duzo pomylek albo zabrne w slepe uliczki to po prostu nie zdaze sie obronic ... a to by nie bylo przyjemne...


NuLL
spojrzyj na to:

http://www.gaiaonline.com/forum/index.php


webhostingtalk ( ktory zreszta czesto przegladam ) to nic w porownaniu z tym - tam jest masa optymalizacji podobno zeby to dzialalo... chociaz nie wiem do konca co lanzer tam po wprowadzal

do zmierzenia wydajnosci uzywam:
http://www.microsoft.com/downloads/details...&displaylang=en
i polecam jesli masz jakis wolnostojacy komputer w sieci.

no ale po co mierzyc? ten pomysl jest poroniony :] zeby na cos takiego wpasc i jeszcze wierzyc ze to moze byc dobry pomysl trzeba byc nie tylko doktorem, ale od razy profesorem

no bo i co z tego ze to troszke skroci czasy wyszukiwan, jak nam udu... (za przeproszeniem) mozliwosc skladania zlozonych zapytan. cala teoria i praktyka o modelowaniu baz danych ida w tym momencie w piz...

to chory pomysl :]
ten czas jaki sie w ten sposob zyska mozna zyskac w innych miejcach nie ponoszac az tak duzych strat w mozliwosiach.

p.s
zapytaj sie tego promotora czy on by chcial miec taka chate - tj. poko na 1 ulicy, kuchnie na innej, lazienke na kolejnej itd.

masz jakies pomysly na tym zyskiwaniu w innych miejscach ? wlasnie po to jest ten temat zeby ludzie wpisywali swoje pomysly na optymalizacje.

(co do tych mozliwosci to podejrzewam ze to forum nie bedzie mialo zbyt duzych ;-) bo nie taki jest jego cel.)

Dobry projekt bazy danych. Czyli ładne relacje, indeksy, ...

Jednym słowem na bazie optymalnie zaprojektowanej, która zachowuje zasady normalizacji baz łatwiej się pracuje i można osiągnąć "małe czasy jej wykożystywania".

Zapytania nie będą trwały długo a odpowiednio napisane zdejmą ciężar pewnych rzeczy z php.

Jeszcze raz powiem:
Pomysł z dzieleniem tabel pod fora to pomysł poroniony i chory.

No weś na przykład wyszukaj wszystkie posty autorstwa mike_mech i przeanalizuj jak to zrobisz na "normalnej bazie" i na ... "innej"

Gwarantuje Ci że nawet najprostsze żeczy bedą u Ciebie wtedy bardzo spomplikowane.

Rozbijając bazę na tyle tabel nie zyskasz NIC a stracisz bardzo wiele.

Czesc osob piszacych w temacie zachowuje sie jak generatory problemow ktorych tak naprawde nie ma. Wymyslacie rozwiazania absurdalne ktore tak naprawde nie sa nikomu potrzebne.

Zrozumcie ze dla MySQL-a 3 czy 5 milionow rekordow to nie tak duzo.

problem ten mozna rozwiazac korzystajac z MERGE storage engine (w przypadku MySQL) - http://dev.mysql.com/doc/refman/5.0/en/mer...age-engine.html , ale to tylko informacja, a nie dyskusja nad tym ktore rozwiazanie lepsze ;-)

A nie prościej stworzyć jedną dużą tabelę i podzielić na partycje?

no ok, to problem dzielenia for na poszczegolne tabele mozna odrzucic ( cociaz wyszukiwanie postow to sprawa dziecinna - nie music byc pelnej funkcjonalnosci jak np. posty z wszystkich for - musicie to zrozumiec ze ten projekt nie zaklada pelnej funkcjonalnosci forum "komercyjnego" )

prosilbym o pomoc a wlasciwie o linki do materialow odnosnie optymalnego planowania baz danych ( nie mySQL - to ma dzialac na innych bazach tez ) - ew. sugestie wlasnie rozplanowania bo na sql malo sie znam

HAWK

a jak podzielisz tabele (bo rozumiem ze chodzi ci o plik ) na partycje, na windowsie ?

To proponowalbym poznac sie, bierzesz sie za cos o czym nie masz pojecia. Forum heavy-duty bez za dobrej znajomosci sql - swietny pomysl.

bez przesady ;P sredio skomplikowane forum , bez bajerow typu templaty itp. samo w sobie bym napisal bez problemu, tylko ta kwestia " dobrego rozplanowania " bazy , mnie martwi wlasnie - jak to zrobic najoptymalniej.
Ale wracajmy do tematu :]

przejdz wszystkie kroki normalizacji i stworz sobie schemat ERD, stworz zapytania, wypelnij przykladowymi danymi i wtedy testuj np. uzywajac EXPLAIN tak zeby wybrac najoptymalniejsze. mysle, ze nikt tu nie da ci zlotego srodka czy reguly jak to powinno wygaldac (przynajmniej tak na sucho odpowiadaja na pytania "jak najoptymalniej cos zrobic"), za duzo mozliwych opcji moze miec takie forum, wszystko zalezy od zalozen i wymagan projektu.

z reguly najwiekszym problemem w forach jest wyszukwianie, ale wiekszosc for radzi sobie z tym tworzac specjalny search_cache. poza tym, przejrzyj sobie dostepny opensourcowe fora jak phpbb, punbb i inne i zobacz jakie tam rozwiazania zastosowano...

a swoja droga ze ciazko to bedzie zrobic pod wszystkie mozliwe BD. rozumiem ze mozna wybrac np 3-5 najpopularnijszych. bo jesli pod wszystkie to bedzie problematycznie z optymalizacja. bo to co zyskamy zyskamy w wiekszej czesci wlasnie na bazie.

swoja droga ze musisz poczytac o opcjach konfiguracji mysql, pgsa i innych. to tez sporo daje. swego czasu bawilem sie roznego rodzaju buforami itd. w mysql i wniosek byl jeden -> baze mozna i trzeba skonfigurowac pod dany sprzet i zeby bylo zabawniej nigdzie nie pisze co i jak pod dany sprzet bedzie najlepsze, trzeba zmieniac parametry tak na zdrowy rozsadek i mierzyc czasy - mi testy roznych konfiguracji, przy roznych obciazeniach bazy zajely 2 tygodnie.

szczerze to jesli piszeszesz ze nawet nie znasz za dobrze sqla - masz problem :]

ja to widze tak: indexy zrobione z glowa to po pierwsze, cachowanie drugie, dobra konfiguracja trzecie. razem jak to zrobic jak nalezy powinno troszke dac.

ja widze to tak zeby to byl mysql, oracle, postgres, hm... sqlite i to powinno starczyc moim zdaniem, chyba ze zapomnialem jeszcze o czyms popularnym.

a to ze mam problem to niestety wiem ;-)

Echhh, następny marzyciel, który myśli, że napisze apkiację pod wszystkie bazy danych. Nawet pod trzy możesz nie napisać.
Hmm, to znaczy napiszesz, ale nie będzie to zbyt optymalne.
Nie da się tego zrobić. Pod każdą bedzie działało troszkę inaczej.

Nastaw się na jedną bazę, max. dwie.

ja na starcie zakladalem ze to bedzie oparte na mysql4 ( innodb ) i php, widzisz problemem jest to ze moj promotor sobie wymyslil ze ma to dzialac na roznych bazach, i teoretycznie zalozenia maja byc tak skonstruowane to dzialalo na roznych bazach a nawet zeby teoretycznie sie dalo przeniesc na inne jezyki programowania.

Totez stad sie biora rozne kombinacje alpejskie typu kazde forum w oddzielnej tabeli itp.

bo sposob w jaki to ma byc wykonane jest chory ( zgadzam sie z wami ) ale musze to jakos zrobic bo inaczej studia na marne eh.....

moze oprocz cache macie jakies inne pomysly ktore to moga przyspieszyc ?

nie ma sie co martwic ze wyszukiwarka przestanie np. dzialac albo ze jakiegos innego bajeru sie nie da wdrozyc, zapytania chcialbym zeby byly jak najprostsze, nie musi byc cudow na kiju.

jest pomyslem zrobienie jakiegos cyklicznego rotowania for na zasadzie dane sprzed miesiaca przenosimy do jakiegos archiwum i user ma do nich dostep tylko przez np "przeszukaj archiwum" itp. Wiem ze truje i wymyslam herezje ale tak wlasnie to ma byc zrobione, i niestety musze sie do tego jakos dostosowac.

dlatego starajcie sie nie pisac ze tak sie tego nie powinno robic ( ja to wiem tak jak wy ), raczej trzeba sie zastanowic jak takie cudo w ogole zaplanowac i wdrozyc...
dzizas ja sie chyba powiesze... a temat wygladal prosto....

PS.
jak zareaguje moj promotor jak do niego przyjde i powiem "nie da sie tego zrobic? "

A może to zadanie jest podchwytliwe?

Jeżeli natomiast będzie to proste forum a'la forum.o2.pl
To nie powinno być problemu z roznymi zapytaniami do baz danych

tak, dokladnie - to ma byc proste forum, bez bajerow, moze nawet cos w stylu tego co pokazales , z ladniejsza grafika ofkors ;P

jesli zadanie bylo by podchwytliwe trzeba by naprawde mase materialow i tez przedstawic ze sie tego nie da dobrze zrobic ( ogolnie trzeba zrobic tak ze dzy dzialalo ale nie tak dobrze jak moze by dzialalo ;-) ) i udowodnc to przed komisja . tego typu zadanie jest trudniejsze niz wykonanie samego skryptu moim zdaniem

takze ja mysle ze jednak to zrobie - jakos...

zadnych zaaswansowanych zapytan do bazy czy innych bzdyr, najprostsza droga - mamy 3 miliony wpisow to wyrzucamy 290000 wpisow do jakiegos archiwum reszta jakos cacheujemy i voilla ;-) wiem ze to brzmi kretynsko ale czym wiecej mysle o tym jak to moj promotor widzi tym bardziej wydaje mi sie ze wlasnie w taki sposob to mialo by dzialac ;-)

Nie. Chodzi mi o tabele, nie o pliki. I o partycje tabeli, nie Windowsa. Problem polega na tym, że ja już poniżej Oracla się nie bawię. Dlaczego? Własnie dlatego, że Ty musisz kombinować z rozbijaniem jednej tabeli na kilka, a ja mogę sobie założyć partycje i mam szybciej, łatwiej i lepiej.

OT: @hawk nie eksponuj tego, czym się bawisz a czym nie. Chcesz powiedzieć, że Oracle jest bardzo dobre do takich zastosowań to powiedz, ale nie ubieraj tego w przechwałki.

Re OT: Oracle dobre jest do wszystkiego... tylko strasznie drogie. Zawsze jest coś za coś.
Ja się bynajmniej nie przechwalam. Przecież to nawet nie jest mój Oracle . Na mysqlu banku nie postawisz, i nie odczuwam specjalnej radości ani dumy pracując na takiej bazie danych, a nie innej. Mogę pracować nawet na zwykłych plikach i wyniki będą współmierne do włożonej kasy.