2010/11/5 Quamis <qua...@gmail.com>: > 2010/11/5 Petru Ratiu <rpe...@gmail.com>: >> 2010/11/5 Quamis <qua...@gmail.com>: >>> 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?
* caching timp de X secunde/minute * temporary table cu max. 100 de items din care faci cautarea * probabil si altceva > >> >>> 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. Nu, partea cu eficienta se traduce direct in bani, pentru ca un query scris cu curul poate induce 10% mai multe servere. Da' ma rog, cand te specializezi in "take the money and run" nu te intereseaza eficienta decat "cat de repede pot convinge gugustiucul sa ma plateasca". Aia pe care pica magareata sa intretina rezultatele pe termen lung au interesul sa convinga clientul sa includa si criteriul de eficienta in specificatii. > >> >>> 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. > PEBKAC, really. http://en.wikipedia.org/wiki/Cursor_%28databases%29 Sincer, dupa un numar de ani de lucrat cu baze de date, ar fi o idee buna sa te interesezi ce-s alea si cum lucreaza, nu sa plangi ca e o problema de UI. >> >>> 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 > Ba da. Ma rog, nu merg in situatia "i don't know and i don't care, trebuie doar sa-i iau banii astuia sa caut urmatoarea victima". -- Petre. _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
