SQL primul produs din fiecare categorie

[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

[Ciprian.Olaru]

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

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

[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...si nu am inteles ce inseamna "numar fix" de categorii.

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

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

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

[resahc]

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

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

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.

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

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

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

[Butcher]

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.

[resahc]

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)

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