SQL primul produs din fiecare categorie

Am un tabel cu sute de produse.
De forma: ID | produs | categorie
Sunt 10 categorii.

Cum pot sa scot intr-un querry ultimele 10 produse introduse, dar categoria sa fie distincta. Adica ultimul produs introdus in fiecare categorie.

Am incercat si cu MAX, WHERE IN () si cu DISTINCT si nu mi-a iesit. DISTINCT e cel mai apropiat dar nu pot sa scot decat cate un camp cu el (adica doar categoriile distincte dar fara id sau detalii).

Exista vre-o posibilitate sa folosesc DISTINCT selectiv, doar dupa categorie?
Adica ceva de genul SELECT id_produs, detalii DISTINCT categorie ORDER BY id_produs DESC LIMIT 0,10;

Sau alta metoda? Nu vreau sa fac 10 querry-uri.

Multumesc anticipat.

Incearca cu urmatorul select

Cod:

---

select p.*
from produse p
join (select categorie, max(data_introducerii) from produse group by categorie) cat
on p.categorie = cat.categorie and p.data_introducerii = cat.data_introducerii

---

Cod:

---

SELECT DISTINCT(categorie) AS categorie, produse.*
FROM produse GROUP BY categorie
ORDER BY id DESC
LIMIT 0,10

---

P.S.: Query nu querry...ai scris de 2x asa deci nu mai e typo :|

Sorin, nu sunt asa avansat in SQL ca sa inteleg. Daca nu ma descurc in alt fel o sa incerc si abordarea ta. Apreciez raspunsul, totusi.

Butcher, e foarte aproape de ce vroiam, doar ca in loc sa-mi scoata produsele cu cel mai mare ID le scoate pe cele cu cel mai mic id, din fiecare categorie. Order by id face cu totul altceva.

A si distinct e cu paranteze? ca la mine nu vrea decat fara paranteze. Iar rezultatul e acelasi cu GROUP BY.

Citat:

---

Query nu querry...ai scris de 2x asa deci nu mai e typo

---

ha ha ha, made my day...mai ales cu smile-ul cel serios. Imi fac autocritica si nu o sa se mai repete o asemenea grava eroare.

brb :)

nu stiu daca merge , dar mi-a venit acum pe moment :

Cod:

---

SELECT * FROM baza WHERE categorie='categorie' ORDER BY id_produs ASC LIMIT 10

---

acel order by id face sortarea tabelei finite (dupa ce se aplica group by) si de asta pare sa nu functioneze;

un posibil indiciu aici: http://dev.mysql.com/doc/refman/5.0/...group-row.html

mda, eram in graba, am uitat ca sortarea se aplica asupra rezultatelor ramase dupa WHERE/GROUP BY/etc

asa ar tb sa fie ok

Cod:

---

SELECT MAX(id_produs), id_cat
FROM t_produse
GROUP BY id_cat
ORDER BY MAX(id_produs) DESC
LIMIT 0, 10

---

queryul asta ar trebui sa functioneze doar pentru a returna lista de iduri pentru produsele cautate;
am un "bad feeling" ca nu suporta adaugarea a unei alte coloane langa (va scoate corect idurile cele mai recente din fiecare categorie, dar numele va fi in continuare al primului produs adaugat in acea categorie);

stiu ca am avut problema asta la un moment dat si solutia a fost sa fac un "select in select" ca sa o pot rezolva (un select era chiar asta si altul era un select standard pe tabela care "se hranea" cu multimea rezultata aici - parca sintaxa era cu select . from tabela where id in (select....) );

pot sa incerc o rezolvare concreta daca imi dai un fisier sql cu cateva randuri reale de tabel;

am presupus aici ca numarul de categorii din sistem este de exact 10.. alfel situatia se complica pentru ca trebuie si un limit pe undeva

Citat:

---

Postat în original de Butcher

mda, eram in graba, am uitat ca sortarea se aplica asupra rezultatelor ramase dupa WHERE/GROUP BY/etc

asa ar tb sa fie ok

Cod:

---

SELECT MAX(id_produs), id_cat
FROM t_produse
GROUP BY id_cat
ORDER BY MAX(id_produs) DESC
LIMIT 0, 10

---

---

Citat:

---

Postat în original de gabriel.stancu

queryul asta ar trebui sa functioneze doar pentru a returna lista de iduri pentru produsele cautate

---

intr-adevar, pt a afla totul tb subquery...

Cod:

---

SELECT * FROM t_produse WHERE id_produs IN(
SELECT MAX(id_produs)
FROM t_produse
GROUP BY id_cat) ORDER BY id_produs DESC LIMIT 0, 10

---

solutia asta, totul intr-un singur query e lenta pe o tabela cu mii de produse, ori se face caching la ea ori se sparge in bucati. Si nu merge pe mySQL 3.xx, parca tb macar > 4.1

Daca ai un numar fix de categorii se poate mult mai simplu :

select distinct(id_cat) as idcategorie, nume as produs, produse.id as idprodus, catname as categorie
from produse,categorii
where produse.id_cat=categorii.id
group by idcategorie
order by idprodus desc
limit 0,5
(unde 5 e numarul tau de categorii)

Evident in lista de campuri se poate adauga ce mai ai tu nevoie

da, poate e mai simplu daca sunt doua tabele (produse si categorii), dar eu intelesesem din enunt ca ar fi una singura ce contine toata informatia

Citat:

---

Postat în original de resahc

Daca ai un numar fix de categorii se poate mult mai simplu :

select distinct(id_cat) as idcategorie, nume as produs, produse.id as idprodus, catname as categorie
from produse,categorii
where produse.id_cat=categorii.id
group by idcategorie
order by idprodus desc
limit 0,5
(unde 5 e numarul tau de categorii)

Evident in lista de campuri se poate adauga ce mai ai tu nevoie

---

Nu e corect, s-a discutat despre asta pe pagina anterioara, order by se aplica dupa where si group by. In felul asta nu afli ultimele produse adaugate...si nu am inteles ce inseamna "numar fix" de categorii.

Si inca ceva, e de evitat produsul cartezian in selecturi, e f lent.

Cod:

---

from produse,categorii
where produse.id_cat=categorii.id

---

Citat:

---

Postat în original de resahc

Daca ai un numar fix de categorii se poate mult mai simplu :

select distinct(id_cat) as idcategorie, nume as produs, produse.id as idprodus, catname as categorie
from produse,categorii
where produse.id_cat=categorii.id
group by idcategorie
order by idprodus desc
limit 0,5
(unde 5 e numarul tau de categorii)

Evident in lista de campuri se poate adauga ce mai ai tu nevoie

---

@gabriel_stancu - scuze...eu am inteles ca ar fi 2 tabele (asa mi se pare si mult mai logic pentru a evita redundanta datelor). Iar in cazul unei singure tabele situatia e mult mai simpla....

Citat:

---

Postat în original de Butcher

Nu e corect, s-a discutat despre asta pe pagina anterioara, order by se aplica dupa where si group by. In felul asta nu afli ultimele produse adaugate...

---

N-am inteles unde e problema, order by iti intoarce ultimele produse care indeplinesc criteriile respective. De fapt le sorteaza....dar intelegi ideea :)

Citat:

---

Postat în original de Butcher

si nu am inteles ce inseamna "numar fix" de categorii.

---

Daca numarul categoriilor se va schimba in timp va trebui sa modifici si limit-ul.

Citat:

---

Postat în original de Butcher

Si inca ceva, e de evitat produsul cartezian in selecturi, e f lent.

Cod:

---

from produse,categorii
where produse.id_cat=categorii.id

---

---

Daca ai 2 tabele relationate, cum altfel scoti intr-un select campuri din ambele?

Te sfatuiesc sa incerci selectul pe un tabel real cu date, o sa vezi ca nu iti intoarce ultimele produse adaugate :).

Selectul cu MAX() face ce trebuie, pe testate :)

In loc de produs cartezian exista LEFT/RIGHT JOIN.

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

1. Tocmai ca am incercat pe o tabela reala inainte de a posta. Doar ca eu am testat pe configuratia cu 2 tabele ca asa am inteles ca sunt organizate datele si in cazul de fata.

2. N-am zis ca nu merge varianta ta...doar ca mi se parea ca te complici inutil.

3. Peste tot pe unde am citit scria ca nu exista diferente majore WHERE vs JOIN la nivel de performanta ci doar ca join intoarce si rezultate din tabela x care nu au neaparat potrivire in tabela y. Dar nu te contrazic, e posibil sa ai dreptate.

4. Am specificat clar de ce conteaza numarul de categorii in varianta mea. (vezi limit)

Citat:

---

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!

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

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.

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.

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.