Haszprus

Komment: waiting

©   Haszprus   |   fejlesztés
Ú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.

RSS: hozzászólások ehhez a bejegyzéshez 19 hozzászólás

Szólj hozzá Te is!

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

Ez valami jogászgondolkodás?!!4

igen, és mint a mellékelt ábra mutatja, jelen esetben például hatékony lenne a szűrő

lol
á, a tartalom alapján történő értelmes szűrés ennél lényegesen komplikáltabb, az új júzerek legtöbbje viszont általában fasságokat ír, úgyhogy ez így jó. aki tovább marad itt egy hétnél az általában nem fikázni jár ide (kivétel erősíti a szabályt).

vmi hiba csuszott a szamitasba, oldalt 6 kommentet mutat a friss temak ennel a postnal, viszont csak 4 van.

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.

es ha mondjuk a friss temakhoz beletennel egy where status != waiting-et?
(nem ismerem a kodot, lehet h nem ennyire egyszeru )

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

hm, meg mindig nem tokeletes, most meg kevesebb jelenik meg
en ezeket jobban szeretem az eredeti tablakbol megoldani, 100 bejegyzes alatt nem veszesen lassabb.

most már csak egy elírás volt, thx

alapvetően nemcsak a sebesség miatt van külön db-vel megoldva, hanem sajnos nem áll módomban subqueryket írni az sql-be (mysql 3.x ), így elkerülhetetlen egy plusz tábla létrehozása a friss témákhoz.

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)

ez a 3 query véletlenül nem sokkal több query egy ciklus révén? (marha fáradt vagyok de nekem most úgy tűnik)


select distinct bejegyzes_id from komment
while {
    select cim, datum
    kommentszam select
}

ha meg a hozzaszolokat is hozzaveszem akkor 4

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.

$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...)

abban nem vagyok biztos, hogy a fetch-es dolgok effektive inteznek-e kerest az adatbazisszerverhez, vagy csak a mar lekert cuccokat adjak vissza megfelelo formaban, de utobbira tippelek.
a tied sem rossz megoldas, mindkettonek vannak elonyei es hatranyai.

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)
Hozzászólásod:


Nem vagy bejelentkezve, de...

A)
hozzászólhatsz regisztrálatlanul...

B)
ha regisztrálva vagy, bejelentkezhetsz...