SQL primul produs din fiecare categorie

[big]

Nu conteaza numarul de categorii, omul vrea ultimele 10 produse adaugate, dar sa fie din categorii distincte.

Corect, sunt mai multe categorii, am zis 10 ca sa nu complic enuntul.

Ideea cu un singur tabel e din obsesia mea de a avea un singur query (sic) per pagina generata. Din motive de performanta. De ex. urasc wordpressul care are un milion de fisiere si face 30 de query-uri sa afiseze un articol de 3 randuri.

Inca nu am revenit la problema ca sa vad care varianta merge, ieri am stat toata ziua pe asta si nu mai am chef sa incerc acum. Din ochi cred ca varianta lui butcher merge, dar o sa confirm cand o sa incerc.

Doar ca mi-a dat si raspunsul si m-a si desumflat intr-un singur post. Daca fac totul intr-un query dar merge mai greu decat cu 2 separate atunci nu merita, mai bine fac 2 tabele si gata.

Oricum, multumesc mult pt raspunsuri, e mare lucru sa te chinui cu ceva o juma de zi si apoi sa intrebi aici si sa vezi oameni care aloca timp si resurse sa iti raspunda. Am dat reputatie la toti ce au raspuns, multumesc!

[resahc]

Se folosesc mai multe tabele (normalizarea bd) pentru a elimina redundanta datelor.
De ex daca ai 10 categorii si la fiecare din ele trebuie sa retii nume, descriere, etc...folosind o singura tabela va trebui sa retii la fiecare produs in parte inca X campuri inutile referitoare la categorie => o categorie stocata de 100 de ori la 100 de produse pe cand o poti avea o singura data. Ca sa nu mai luam in calcul situatia in care as vrea sa modific numele unei categorii...

Iar legat de un singur query ...se pot scoate date nu din 2 ci din cate tabele vrei dintr-un singur query...folosind where SAU JOIN

[big]

Categoriile sunt in tabela separata. In produse am doar id-ul categoriei. Macar atata optimizare m-a dus si pe mine capul

Ma gandesc acum sa creez un al treilea tabel cu ultimele 10 inregistrari, care sa fie actualizat la momentul adaugarii unui produs. Pt ca mai bine fac 2-3 query-uri (ce aiurea suna domnule cu un singur r, pe bune acuma, ma zgarie pe creieri) la o adaugare, decat la mii de afisari. Cred ca e cea mai eficienta solutie. Si din tabelul asta scot datele cu un singur query simplu si rapid.

[resahc]

Daca nu ai actualizari foarte frecvente e buna ideea cu o tabela temporara.

Eu folosesc o chestie de genu pentru o sectiune "recomandarile zilei" si pentru ca n-avea rost sa rulez un query destul de costisitor la fiecare accesare mi-am facut un cron care la 12 noaptea populeaza o tabela temporara cu X inregistrari...si apoi toata ziua doar afisez tabela aia.

[Butcher]

resahc

Sql-ul tau nu intoarce ultimul produs adaugat in categorie, despre asta vorbeam si cu grabriel.stancu. Greseala asta am facut-o si eu in primul sql postat.

Ti-am testat sql-ul a 3-a oara, pe 2 tabele, ca asa am si eu.
Nu conteaza cum ai baza de data structurata, cu 1 tabel sau normalizata cu 2. id_produs returnat de sql in momentul cand faci "GROUP BY by id_cat" este un id aiurea.

NU ESTE ID-ul ULTIMULUI produs adaugat in categoria respectiva.
Pentru ca ORDER BY se aplica la sfarsit pe setul de date rezultat, nu se face ORDER BY id_produs DESC mai intai, urmat de GROUP BY.

ORDER BY se aplica abia dupa ce ai:

3 - produs x
1 - produs y
2 - produs z

el iti ordoneaza 1,2,3 rezultate. Nu stiu daca am explicat destul de clar. Lucru acesta l-a observat si gabriel.stancu

[Ciprian.Olaru]

o alta solutie (chiar si mai rapida) e sa faci acest cache intr-un fisier html sau tpl de ex (evident.. la adaugarea unui nou produs in db regenerezi acest html cu un script tip trigger atasat) si astfel elimini si pasul in care faci un query (cu indiferent cati "r" ar fi el ) la fiecare afisare;
practic, o bucata din pagina devine statica dpdv al afisarii.. dar apare dezavantajul ca o viitoare dezvoltare (de exemplu una grafica) are nevoie de ceva mai multa atentie la codare;
plus ca varianta asta merge cand ai lista asta cu produse in 1-2 locuri si nu in 100;
cu ceva atentie la scriere (cum ar css 100% in afara bucatii cacheuite) poate sa iasa o chestie simpla si eficienta (solutie testata personal);

Categoriile sunt in tabela separata. In produse am doar id-ul categoriei. Macar atata optimizare m-a dus si pe mine capul

Ma gandesc acum sa creez un al treilea tabel cu ultimele 10 inregistrari, care sa fie actualizat la momentul adaugarii unui produs. Pt ca mai bine fac 2-3 query-uri (ce aiurea suna domnule cu un singur r, pe bune acuma, ma zgarie pe creieri) la o adaugare, decat la mii de afisari. Cred ca e cea mai eficienta solutie. Si din tabelul asta scot datele cu un singur query simplu si rapid.

[resahc]

@Butcher - ai dreptate...nu am fost foarte atent la aspectul asta.
Scuzele mele.

[Butcher]

@Butcher - ai dreptate...nu am fost foarte atent la aspectul asta.
Scuzele mele.

se intampla

Legat de caching. Abordarea mea
Clasa mea de BD are implementat caching cu fisiere.

Adica:

$arr_result=$db->sql("SELECT * FROM tabel", 3600); 

3600 = timpul in secunde cat este valabil cache-ul.

Creez un fisier ce are ca nume md5($sql) si in el stochez array-ul rezultat din baza de date serializat.

Daca se mai executa acelasi sql, inseamna ca am un fisier cu numele md5($sql). Aflu data crearii fisierului (este functie php). Daca timpul curent - data fisierului < 3600 => cache hit si citesc array-ul serializat din fisier + unserialize;

Daca nu e cache hit execut sql-ul si stochez rezultatul in fisier.

In felul asta am un sistem de caching customizabil pt fiecare caz particular in parte fara cronjobs/etc.

[Ciprian.Olaru]

de acord cu cachingul cu serializare, dar in cazul asta concret s-ar putea sa dureze mai mult lucrul cu fisiere decat queryul intr'o tabela tip cache in db;
in plus, eu prefer sa "expir" cacheul in momentul in care fac o modificare in db (care afecteaza bucata respectiva) in loc sa calculez dupa timpul trecut de la generare;
sunt si situatii in care prefer sa am o intarziere in "propagarea" datelor de la adaugare pana la afisare (cache bazat pe timp de valabilitate), situatii legate de obicei de homepage, dar ca numar de situatii prima varianta se potriveste in mai multe locuri (conform preferintelor / experientei mele);