Stvari postaju jasnije od kuda toliko teoretskog naklapanja, a nula praktičnog rada, nula svjesnosti realnih ograničenja prilikom rješavanja realnog problema (a ne onog iz udžbenika) i shvaćanja upotrebljivosti određenog znanja u određenom momentu.
U svakoj teoriji postoji idealno stanje i praktično. Matematičari su ti koji sve idealiziraju, fizičari se već približavaju praktičnim primjerima, a tek strojari i slični primjenju tu fiziku. U primjeni uvijek postoji jedan veliki odskok od teorije…koji se većom mjerom steče iskustveno te se i formiraju konstante koje nadopunjuju teoriju do kojih se došlo također iskustveno, a ne nekakvom egzaktnom matematikom.
Meni se čini da si ti teški teoretičar, što dokuzuje i tvoj pristup ovom konkretnom problemu…a općenito sam te više nego dovoljno puta pročitao da to shvatim. Ovim gore citiranim si mi samo to potvrdio.
Svaki realni problem ima nužan cilj koji se mora ostvariti i ograničene resurse da se do toga cilja dođe. Realne probleme najčešće nije moguće (ili nije isplativo) riješiti “idealnim” metodama, jer će se do konačnog rješenja doći nikada i uz enormno skupe resurse da se tamo dođe.
!!!Što nikako ne govori da je teorija loša, od tuda naravno sve polazi. Ali za konretan problem se treba znati prilagoditi problemu…a ne pokušati mijenjati svijet po sebi i nekakvim ne ostvarivim idealima. Kao što je mitok imao “odlično” rješenje za Koronu, ali 100% nesprovedivo unutar realnih ograničenja…
@drmko, ne obeshrabujem ovim tebe da unaprijediš svoju strukturu…ali ti si svakako najbolje svjestan što ti se isplati uvoditi što ne. Koliko sam ja uspio opaziti, ne trebaš nikakva značajna restrukturiranja baze, korisno bi ti bilo samo da si vodiš koji atributi filtera ti pripadaju kojoj kategoriji. Ako je relacija između filtera i kategorije jedan na jedan, onda ti niti ne treba zasebna tablica, nego samo u tablici gdje su filteri, dodaš polje koje će označiti kategoriju.
Hoće li to olakšati sam upit/select…nope. Osnova za upit ti je ono što ti je @avetma napisao i to ti je daleko najkorisniji info koji si dobio u ovoj temi vezan uz tvoje pitanje.
No jednom kada si deklariraš kojoj grupi ti pripada koji filter (i nakon što ćeš imati informaciju o tome koja grupa filtera je hijerarhijski iznad neke grupe), onda možeš uvoditi više levela automatizacije koje sada vjerovatno nemaš.
Ali ni to ti značajno ne mijenja stvar…jer ti tu informaciju već negdje sigurno imaš, iako možda nemaš u bazi.
Gdje si tu informaciju zapisao?
Pa ako u frontendu imaš zasebno izbornik filtera po pojedinim kategorijama, onda si samim tim separiranjem filtera razdjelio ih u zasebne grupe/kategorije. Nije najspretnije da ti ta informacija stoji u front-end dijelu, ali nije da stvar i tako neće šljakati. Kada korisnik poklika filtere…ti iz toga dijela znaš koji filter stiže iz koje grupe, pa si sposoban iz toga producirati query koji će znati koje filtere treba razdjeliti sa AND uvjetom, a koje sa OR uvjetom. (Jer znaš od kuda stiže koji filter, tako da tu informaciju očito imaš.)
E sad, kada bi tu informaciju imao negdje drugdje (prije frontenda), onda bi bio sposoban podići level automatizacije na način što bi onda mogao dinamički generirati izbornik filtera po kategorijama…isto tako bi se ta informacija skroz protezala do generiranja query-a gdje bi opet automatski mogao posložiti filtere između AND i OR uvjeta, da dohvaćeni rezultat bude po očekivanju.
Ali ponavljam, ti čim imaš sortirane filtere po grupama, ti očito tu informaciju negdje već imaš…al nebi bilo nikako zgoreg da ta informacija stoji u tablicama gdje su i filteri (ili eventualno u zasebnoj tablici). To ti neće nikako naštetitit postojećoj strukturi, a koristan ti je updejt za dalje.
Jer je cilj uvijek imati informacijski dio razdvojen od programskog code-a. Prosto iz razloga što je tako lakše održavati program. Jednom kada zatrebaš uvoditi nove stavke filtera, elegantno je ako ne moraš pipnuti nigdje u code, nego samo nadopunjuješ informacijski dio