Úgy alakult hogy végülis megoldottam, hogy a regisztrálatlan, ill. egy hétnél frissebben regisztrált júzerek kommentjei először waiting státuszba kerülnek, aztán vagy jóváhagyom a kommentet, vagy nem. Köszönhetően az "értelmiség" elszánt jelenlétének.
valamilyen filtert is lehetne írni e célra, pl ha valaki egymás után háromnál több kérdőjelet/felkiáltójelet tesz, esetleg két felkiáltójel után vagy egy négyes, akkor spamnek minősül a komment

válasz
elég hosszas scriptmódosítás kéne ennek a maradéktalanul tökéletes lekezeléséhez, egyelőre betettem a teendőim közé. konkrétan most már csak annyi a bug, hogy ha egy waiting komment kerül beírásra első kommentként egy bejegyzéshez, akkor is meg fog jelenni a friss témák listájában 1 kommenttel, míg ha a user ellapoz a komment.php-re, ott nem fog hozzászólást találni.
update: hm úgy tűnik közben véletlenül ezt is megoldottam
ehhez már igazi zseninek kell lenni, hogy tökvéletlenül oldjon meg az ember problémákat.
update: hm úgy tűnik közben véletlenül ezt is megoldottam

a friss témák listáját egy külön erre készített db-ből nyerem, ahol minden hozzászólással rendelkező témához egy darab rekord tartozik. mert ez így gyors, meg mintha valami más oka is lenne, de arra már nem emlékszem, talán a régi mysql szerveren nem lehet(ett) megoldani subquery-kkel az ügyet. nem tudom már, nagyon rég volt, meg mindegy is.
(ja szóval ebben a db-ben nincs a topicokhoz státusz rendelve.)
(ja szóval ebben a db-ben nincs a topicokhoz státusz rendelve.)
en sem subqueryvel csinalom (legalabbis hagyomanyos ertelemben), hanem pl az aktiv temaknal id alapjan csokkeno sorrendben kivalasztom az utolso x kulonbozo hirhez tartozo (distinct) kommentet, aztan hozza bejegyzes_id alapjan a bejegyzes cimet meg a kommentek szamat. ez igy 3 query, de meg megfeleloen gyors sztem.
(amugy vilagok harcanal meg nem egeszen stimmel a szam)
(amugy vilagok harcanal meg nem egeszen stimmel a szam)
most tanultam valamit, erről a while-ról nem tudtam
de ha nem értem félre a mysql.com-ot ehhez is mysql 4.1 kéne
(persze lehet h félreértem)


sztem tudja ezt 3as mysql is. de lehet,h felreertettuk egymast, idekopizok egy peldat.
es akkor ez az utolso 5 friss tema
$q = @mysql_query("select distinct(bejegyzes_id) from kommentek order by id desc limit 5");
while($l = @mysql_fetch_object($q)) {
$post_q = @mysql_query("select cim, datum from bejegyzesek where id = '$l->bejegyzes_id' limit 1");
while($pl = @mysql_fetch_object($post_q)) {
$kommentszam = array_pop(@mysql_fetch_assoc(@mysql_query("select count(id) from kommentek where bejegyzes_id = '$l->bejegyzes_id'")));
echo $pl->cim . ", " . $pl->datum . ", " . $kommentszam;
}
}
es akkor ez az utolso 5 friss tema
oks köszi szóval ez nekem mégiscsak egy rakat querynek tűnik, mármint végrehajtáskor 
az én friss témáim legenerálása összesen 1 db mysql_query, 1x leírva, 1x végrehajtva -> sweet (se ciklus, se subquery)
(persze kommentbeíráskor többminden zajlik a háttérben, de laplekérés napjában átlag 1000x van (ma eddig 1350), kommentből meg 50 alatti a rekord, de az átlag is hasraütök 10 körül mozog...)

az én friss témáim legenerálása összesen 1 db mysql_query, 1x leírva, 1x végrehajtva -> sweet (se ciklus, se subquery)
(persze kommentbeíráskor többminden zajlik a háttérben, de laplekérés napjában átlag 1000x van (ma eddig 1350), kommentből meg 50 alatti a rekord, de az átlag is hasraütök 10 körül mozog...)
A fetch termeszetesen nem intez ujabb kerest az adatbazishoz. Nem is lenne ertelme akkor, hogy eloszor van egy query, aztan a fetch ujbol piszkalgatja az adatbazist, mert akkor egybol lehetne minden adatbazis sorert hozza fordulni, az meg aztan rendesen terhelne a rendszert. Mindenesetre Haszprus megoldasa igy is gyorsabb, csak hat persze tobb tarhelyet hasznal, de ez ugyis olyan kis plusz, hogy nem fogja egyhamar beteliteni a szervert. Egyebkent valszeg en is inkabb a hozzaszolasok szamat es az utolso hozzaszolas datumat tarolnam el egy kulon friss_temak db-ben topikonkent, minthogy minden alkalommal lekerdezzem csokkeno idorendben a topikcimeket es a kommentek szamat, mert az jobban terheli a szervert. Persze ennek jelentosege tenyleg csak extrem latogatottsagi szintnel van, ha ugysem sajat szerveren megy, hanem a szolgaltatoen, akkor meg kit erdekel

nem a mysql_fetch_objectről beszélek, hanem mysql_query-kről amik ciklusban többször hajtódnak végre és a kódot nem akarom túl sokáig értelmezni (csupa olyan functiont használ amit én nem szoktam), de legalább 11 query van benne a db felé, amennyire látom így 10 perccel ébredés után
a lastcomments tábla egyébként pillanatnyilag 84 KB úgyhogy valóban nem fogja a szervert betelíteni
(viszonyítás képpen a bejegyzések táblája 1,6 MB, a kommenteké 2 MB)



