2010/11/5 Petru Ratiu <[email protected]>: > 2010/11/5 Quamis <[email protected]>: >> Ca sa iau pic si partea programatorului... >> ORDER BY RANDOM() e perfect legal si rapid:) > > Pentru anumite valori ale lui legal si anumite valori ale lui rapid... > >> Problema e ca nu face cache, dar nici asta nu cred ca e o problema asa >> mare, din moment ce smecheria asta se intampla fara sa se atinga de >> disk(tabelul e in memorie, doar il sorteaza altfel). > > Daca tabelul e suficient de mic, sau memoria suficient de multa. > >> Sistem quad core e cam degeaba, din cate stiu se tot incearca sa se >> faca mysql-ul sa ruleze multiprocesor, nu stiu daca au ajuns prea >> departe, dar pana una-alta mysql-ul e un singur thread, in mare parte >> disk-bound. Si sincer, din moment ce "clientul" vrea sa aiba pe prima >> pagina articole alese aleator din baza de date... is there another >> way? > Da.
Care? > >> clientul e cel care plateste quad-core-ul, clientul e cel care >> plateste si programatorul, clientul e cel care in final are de >> pierdut... >> > E treaba programatorului sa implementeze eficient ce are _de fapt_ > nevoie clientul, nu doar sa traduca din romana in php. Daca > programatorul decide sa faca ce vrea clientul, sa-i ia banii si sa-si > ia picioarele la spinare, n-are decat, dar sa nu faca pe mironosita > dupa aia. Nu chiar, treaba programatorului e sa implementeze ce vrea clientul. Partea cu eficient, optim, rapid, memorie putina, preferabil scris in assembler tine de mandria si cunostintele programatorului. Nimeni NU mi-a cerut vreodata sa fac ceva eficient si am ~6 ani de lucrat in PHP+MySQL. Deosebirea in cazul meu e ca testele se fac pe seturi relativ mari de date din start, si am fost nevoit din start sa invat de optimizare, index, key primare, diferenta intre TEXT vs CHAR vs VARCHAR si tot asa. > >> Mai zicea cineva de "SELECT SQL_CALC_FOUND_ROWS, etc FROM". Asta e >> varianta optimizata. Intern nu stiu ce face, si in manual nu scrie >> nimic, nu stiu de unde tragi concluzia asta. > > "Mie nu mi-a zis nimeni, deci n-am nici o vina". Dar mi se pare perfect normal ca serverul sa imi intoarca rezultatul atunci cand isi intalneste LIMIT-ul si apoi sa continue cautarea in backgroumd, cat timp clientul isi citeste setul de date... Nu vad nici un motiv pt care intr-o aplicatie ai face de 2x acelasi lucru, mai ales cand e vb de o operatie foarte costisitoare. deaia si ziceam ca mi se pare o problema majora a serverului. > >> Daca e asa, mi se pare o >> problema majura a serverului, nu a programatorului, dar din ce teste >> am facut eu, un select cu SQL_CALC_FOUND_ROWS e mult mai rapid decat >> SELECT cu LIMIT si apoi sa faci inca unul fara LIMIT... Oricum, alta >> metoda sa afli numarul de randuri nu prea ai. >> > Mai ai, trebuie doar sa-ti pese. No there isn't:) exita "workaround"-uri, care nu iti vor garanta niciodata numarul exact de rezultate... si nici alea nu merg pentru orice situatie posibila > > As zice sorry de flama, da' e vineri si ce pana mea. Yeee, a venit vineri in sfarsit:) > > -- > Petre. > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug > -- -------------------------------------------- ----THE END of this transmission---- _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
