SQL primul produs din fiecare categorie

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

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

Citat:

---

Postat în original de 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.

---

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

Citat:

---

Postat în original de resahc

@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:

Cod PHP:

---

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

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

problema apare din faptul ca nu se poate limita group by.
O rezolvare (lenta) este folosind variabile in sql (variabile de mysql).

Daca intereseaza pe cineva o sa incerc sa postez maine o explicatie, acum sunt pe telefon si e mai greu.