Imam tri tabele, jedna glavna proizvodi, druga sa filterima, a treca pro_filters.
U tabeli “pro_filters” imam samo dve kolone “id_pro” i “id_filt” u kojoj je odredjenom proizvodu dodeljeno vise stavki filtera.
Ako imam dva proizvoda:
prvom su dodeljene stavke filtera sa id vrednostima 5 i 7
drugom proizvodu su dodeljene stavke fildera sa id vrednostima 7 i 9
Zelim da izdvojim samo jedan proizvod, prvi kojem su dodeljene vrednosti 5 i 7
Ako postavim ovaj upit:
SELECT * FROM proizvodi p
INNER JOIN pro_filters pf ON p.id = pf.id_pro
WHERE p.akt=1 AND pf.id_filt IN (5, 7) GROUP BY p.id
prikazace mi oba proizvoda, jer je u uslovu IN postavljena 7 koja je dodeljena i jednom i drugo proizvodu, jer taj uslov je ustvari OR.
Kako da preformulisem upit, tako da izdvojim samo proizvod koji ima obe vrednosti id_filt i 5 i 7, a ne i proizvode koji imaju jednu vrednost 7.
Preciznije, treba mi ovakva funkcionalnost: https://www.winwin.rs/racunari-i-komponente/racunarske-komponente/maticne-ploce.html?manufacturer=74454%2C74798
Da kad neko cekira u istoj grupi stavke, na ovom primeru Proizvodjač, upit odradi OR izmedju izabranih stavki, a kad dodatno izaberem nešto i u drugoj grupi, npr Čipset, da odradi izmedju vrednosti dveju grupa AND
Nisam sad pri računalu. Jesi li probao sa LEFT JOINom umjesto INNER JOIN. Probaj još i umjesto AND pf.id_filt IN (5, 7) sa AND pf.id_filt = 5 AND pf.id_filt = 7
SELECT * FROM proizvodi p
INNER JOIN pro_filters pf1 on p.id = pf1.id_pro and pf1.id_filt = 5
INNER JOIN pro_filters pf2 on p.id = pf2.id_pro and pf2.id_filt = 7
WHERE p.akt=1;
Ovo radi i kad nesto modifikujem u upitu, kad se menja broj cekiranih filtera i kad stavim prebrojavanje istih preko php i umesto 2 unesem to.
Problem nastaje sto za jednu grupu filtera (npr maticne ploce), izmedju njihovih ID ide AND, a onda njihova grupa, sa drugom grupom cekiranih stavki filtera (npr Procesori) ide pod OR.
Pod dinamički misli da programski kreiraš SQL zavisno od id-ova koji su uključeni. To bi značilo da ovisno o broju ID-ova moraš imati više uvjeta navedenih u SQL upitu…pa ga programski slažeš po potrebi. (Dinamiči generiraš)
Ali, nije problem dinamički složiti SQL …nego opet moraš znati što želiš složiti. U tome je ključ, a koliko vidim, to nije ponudio.
Ovo što je ponudio avetma, to bi možda moglo raditi.
Nego, tvoj problem može biti lakše/teže rješiv ovisno koliko ti je optimiziranost bitna? Baš moraš sve rješiti sa jednim SQL upitom, ili smiješ nad dohvaćenim podacima upotrijebiti malo dodatne logike/filtriranja.
Jer ako se ne radi o nekakvim teškim optimizacijama, onda lako ovo rješiš sa malo dodatne logike.
Je l’ koristiš redis? Je l’ u pitanju trpanje u keš il’ prosto pretraživanje baze (pokušavam da anticipiram strukturu baze tj. ostale query-je koji se izvode nad istom)?
Djeluje mi manyToMany al’ s obzirom da je to iz request-a djeluje mi da pokušavaš keširanje pretrage i isto tako mi djeluje da bi se ta pivot tabela mogla prepuniti vrlo lako. Je l’ uradjeno i indeksiranje pivota?
Ne koristim redis.
Nikakav keš, pretraživanje baze.
Nema previše upita, konkretno na toj strani.
Ali mi je ovo filtriranje bitno.
Bitno mi je da sad ovo režim da radi, a onda BiH razmišljao kasnije o optimizaciji.
Pod dinamickim sam pomislio da idu neki podupiti (select). Ako se misli na dinamiku da php dodaje to, slaze, to ne bi bio problem, ali da znam sta da slazem
od avetima radi, samo ako bi bilo uvek AND izmedju stavki filtera, a ako bi islo ovako (gde su u zagradi ID filtera), onda nece:
(4 and 5 and 6) or (8 and 2 and 7) or …
Trenutno mi optimiziranost nije toliko bitna, sad mi treba neko prelazno resenje.
Naravno, voleo bih da bude sve u jednom upitu, ali ako nije moguce, onda sta da se radi, ako mora drugacije.
Sad ne znam koliko te razumem.
Svi postojeci filteri po nazivu su smesteni u tabeli “filteri”, a id-ievi filtera dodeljeni odredjenom proizvodu, se svi smestaju u tabeli pro_filters, pa onda za te dve tabele, proizvodi i pro_filters pravim upit koji treba da mi izvuce gore navedeno.
Mozda razmisljas da se pravi vise tabela “pro_filters” za razlicite grupe filtera (maticne ploce, procesori itd), ili gresim, ili pak da se sve organizuje u jednoj tabeli pro_filters, ali uz neke dodatne kolone u toj tabeli?
Dobro si me sve razumio.
Pomaže mi da apstrahujem strukturu.
Meni je prirodno da postoje [odvojene] tabele motherboards, chipsets, rams i sl. gdje je relacija izmedju tabela non identifying. Struktura je kompleksna što rezultuje jednostavnijom nadogradnjom atributa ali i kompleksnih query-ja.
Tako da je to filters samo frontend brand a u stvari treba da filtriraš vrlo konkretne entitete.
Javiću se poslije ručka ako uspijem smisliti nešto.
Meni isto nedostaje par logičkih elemenata u ovoj priči. Možeš na primjeru reći kako si zamislio da ovo funkcionira? Na temelju čega bi se odredilo što je OR, a što AND ako su svi filteri hijerarhijski jednaki u istoj tablici?
