Stránkovaní pomocí seek() – PHP – Fórum – Programujte.com

Co si myslíte o tom, když místo klasického limit offset použiji mysql_data_seek() - http://cz.php.net/manual/en/function.mysql-data-seek.php - plus následné fetchovaní jen potřebného?

Výkonově to bude asi slabší. Použili jste někdy tuto techniku? Výhoda je, že pokud provadím nějaký "asociační post-render" (= na jeden řádek použiji jich více), pak bych s limitet teda popravdě nevystačil...

pockej az tam bude 10000x cca 20kB dat a par uzivatelu naraz ... nejen ze databaze z tebe bude mit radost... furt posilat celou tabulku je velice "efektivni" lepsi uz snad bude spis ty polozky projit a najit ty asociace?
ostatne kdyz bys mel klice a pouzil left join tak by ti to mohlo hodit treba do druhy urovne v jednom radku...
resp kdyby si tam mel dalsi tabulku kde bys mel vsechny spojitosti co k cemu patri :D

Pouzivat vice radku na neseni jednoho udaje je blbost. Databaze jsou navrzene tak aby jeden udaj byl nesen jednim radkem a tak jsou nejefektivnejsi.

Prace s celous skupinou vysledku muze fungovat tak do par set zaznamu, pak to zacne byt neunosne pomale a pametove narocne. Tim samozrejme nerikam, ze limity jsou samospasitelne. Treba v tomhle ti ani limit nepomuze:

SELECT * FROM tabulka ORDER BY RAND() LIMIT 1

To CommanderZ : no on mel asi mozna na mysli neco jako diskuzni forum se stromovou strukturou...

To CommanderZ : He, teda, kdepak. Myslel jsem vztah hasMany...
select posts.*, comments.* from posts left join comments on posts.id = comments.post_id where post.id = 15

Tak ted jsem u ani jedno z vas nepochopil, co se mi snazite rict :)

To KIIV: To ma byt obhajoba toho kdyz vice zaznamu nese jeden udaj? Ja uz stromove forum delal a nevim o tom, ze by to tam bylo nekde potreba.

To hrach: A co se snazis rict timhle? Sry ale fakt mi to nedochazi :)

Teoreticky. Mam dotaz na vyber 10 postu. Nastavim limit 10, vse je ok. Chci dotaz rozsirit na vyber 10 postu vcetne jejich komentaru. Mam problem. Limit bude pocitat vsecky radky. Tedy, pokud prvni post bude mit 10 komentu, pak diky limitu uz nevyberu ani vic postu. Tento problem by odpadl pri pouziti seek() -> respektive tim, ze fetchuji radky jiz "asociovane".

hrach
pokud provadím nějaký "asociační post-render" (= na jeden řádek použiji jich více) … Chci dotaz rozsirit na vyber 10 postu vcetne jejich komentaru.
Proč nepoužít 2 dotazy – proč nejdříve nevybrat posty a potom komentáže k nim? Proč to rvát celé do jednoho?

To CommanderZ : nikde v jeho uvodu nemuzu najit ani zminku o vice zaznamech nesoucich jeden udaj...
asi sem slepej

To bukaj : proc? protoze aby to byly dva sql dotazy, pak musim projit vysledek, a udelat dalsi dotaz na comenty s temi post id, ktere jsem si jiz vycucl. posleze opet projdu vysledek, hle, priradit odpovidajici komenty k odpovidajicim postum a je hotovo. jak oproti prvnimu reseni jednodusi. ANO, NE? nevim, me proste toto nepritahuje.

Ale zpet k tematu, co si myslite o tom seek(). Kdyz sem dnes nad tim premyslel... tak se dosel k zaveru, ze db si musi stejne nejprve vsechny odpovidajici zaznamy najit, a to kvuli razeni....

hrach
jak oproti prvnimu reseni jednodusi. ANO, NE?
Podle mě áno, podle mě je to i správnější a méně to zatěžuje databázi :o) U řešení vybrat to sakumprdum mě zase moc nepřitahuje to si hlídat, co teď mám, či nemám za post a nějak nechápu, jak by v tom seekování mohlo pomoci? Efektivní použití síkování by znamenalo si nejdříve vybrat, kolik má který post komentářů, ne? Nebo máš na to nějaký lepší fígl? :o)

Navíc, pokud jde o to vybrat posty a k nim komentáře, nebudeme přeci vybírat komentáře s informacemi o postu, ne? (Čistě teoreticky, jeden záznam v relaci odpovídá jednomu objektu. Ty vlastně chceš vybrat objekty typu Post, které budou mít, řekněme, vlasnost comments, která bude pole komentářů (objektů typu Comment). Ale když se to dá do jednoho dotazu, vyleze z toho vlastně objekt typu CommentWithInformationsAboutPost, a ne požadované posty.)

Řekl bych, že výkonostně to bude ztrácet při výběru hodně „širokých“ tabulek, či velké sady dat – bude se přenášet hodně redundancí.

A když budeš chtít vybrat posty s informacemi o jejich autorech (autorů může být více) společně s komentáři (komentářů samozřejmě také může být více) a odkazovat na komentáře, které na něj odpovídají (těch samozřejmě může být také více), budeš to všechno spojovat do jedné obrovské relace – hlavně aby to byl jeden dotaz?

To bukaj : byl to priklad. Jeho smysl jiz ponechme. Tedy, uzavreme, zrejme seekovani nebude idealni pri vetsich tabulkach.

Pokud by mel nekdo nejake "zmerene" veci, ci dalsi zkusenosti, necht se podeli :)

pri vetsich tabulkach a pokud tam prijde vic dotazu za nejakej kratkej cas