MySQL upit - jedna kolona vise vrednosti

Kako možeš to zaključiti ako ti nije poznata veličina aplikacije i koliko je skup zahvat restruktuiranja?
Isto tako, kako to možeš zaključiti ako ti nije poznato što se dobiva restruktuiranjem, jer ne znaš koji su daljnji planovi razvoja aplikacije?

Nije isto restruktuirati kada su tek napravljeni temelji…i planira se 20-ero katnica izgraditi nad tim temeljom. Nego kada su već izgrađeni temelji i već je izgrađena 20-ero katnica i sada treba još samo staviti antenu na vrh zgrade…a ti dođeš i kažeš da se isplate mijenjati temelji koji će podržati 50-ero katnicu, koja uopće nije u planu da se gradi, nego samo fali još antena na vrh već gotove zgrade?

Mislim, isplativost je omjer uloženog/dobivenog…tebi nije poznato niti jedno od toga dvoje :wink:

Nebi znao koja je ofišl dokumentacija da potkrijepi ovo gore rečeno, ali siguran sam da je i taj pristup negdje dokumentiran. :wink:

Vidiš, ustvari tebi nije poznato šta sve pokriva kod koji sam ostavio.
A ostavio sam kod koji koristi restruktuiranu bazu u odnosu na onu ostavljenu u postu ovde.

Bez obzira o kol’ko se spratova radilo neke norme se moraju poštovati.
Apstrakcija baze koju koristi eloquent kod blok malo iznad (umnogome) poštuje nf sa pripadajućim relacijama neovisno da l’ se radi o 1, 22 ili 50 spratova.

Tebi je bolje da izučiš zašto se u petlju nikad ne postavlja query baze.

1 Like

@tpojka hvala na odgovoru.
FW mi je nekako sad nedostupan, tj nikad nisam radio sa Laravelom.
Jel mozes da uradis rekonstrukciju onih tabela koje sam dao kao primer, a da ta nova rekonstrukcija, moze da omoguci koriscenje i klasicnih upita, bez FW?

Trenutno pokusavam sa find_in_set sto mi izbacuje tabelu pro_filters, sto opet nije po pravilima, ali ce mozda proraditi :slight_smile:

Ostavio si code koji će teže implementirati u svoj app, nego što bi se moglo implementirati srce majmuna u čovjeka. :slight_smile:

Code koji nadalje sam za sebe ama baš ništa ne govori, bez da se vidi što je iza tih klasa koje se koriste.
Od pukog teoretiziranja, ja rijetko nešto konkretno od tebe čujem. :stuck_out_tongue:

Napis’o sam kako bi to trebalo izgledati tamo. Zato sam i ubacio u off tagove jer nisam siguran kol’ko vremena se ima. Moj rad ti se svodi na najveće vrijeme uzeto za struktuisanje baze da sam 99% siguran da me ne može ništa naknadno iznenaditi i onda sa normalizovanom strukturom rad u eloquent-u je pjesma (u najčešćem broju slučajeva fewliners).

Nisam razmišlj’o al’ ne bi mog’o to (nešto pametno reći) u adhoc odgovoru, već bi mi zahtijevalo neko vrijeme da osmišljavam pametnu™ strukturu tabela a tek poznavajući sve proizvode sa pripadajućim atributima/properties. Iskren da budem, trebalo bi mi neko vrijeme da uočim zakonitosti i dostupne edge cases iz trenutne postavke (kad udješ u pogrešan voz, svaka stanica je pogrešna).

Imaš tamo u adjecency model kako uzeti sve ancestors ili sve descedants.
Tako da primjera radi ako odabereš “Asus” - dobiješ sve children a pomoću tih id-jeva tražiš u trenutnoj pivot tabeli id-jeve proizvoda. Da, i poseban query (tj 3 query-ja) u ovom slučaju: filters, pro_filters, proizvodi brže će raditi od query-ja u petlji.
Ali zatim, ako uzmeš asus pa još neki filter moraš da provjeriš da l’ je taj dodatni filter u children of asus ili eventualno u ancestor’s of asus pa ako jeste treba da isključiš sve descedants of assus osim tog filtera tj, treba da uzmeš njegove descedants only. To je kako na prvu vidim a možda i griješim bez nekog dubljeg testiranja. Prekomplikovano je trenutno da bi’ mog’o da ti ponudim zadovoljavajuće rješenje. Jbg. :mask:

Pa naveo sam da je postavljena elegancija primjenljiva za Laravel + Eloquent kod? :thinking:

'Nuff said.

Btw.

Svidja mi se kad upadneš u evolutivno-biološki mod mada moraš priznati da pomalo zapostavljaš Perinu komponentu.

1 Like

Mjenjaj strukturu baze, s ovim ne mozes bas puno, mislm moze se ali ce te da gresja sjupo stajati u buducnosti isvaka nadogradnja ili novie feature kostat cete puno vise nego sto bi trebao. @trnac ti je dao super primjer i kako bi to trebalo izgledati. Pogledaj si malo Open Source shop systeme kako oni to rade i veces vidjeti da ti struktura bate “ne igra”. Ako imas strukturu slicnu onoj koju ti je @trnac predlozio onda i slican upit koji ti je dao @tpojka nece biti problem implementirati u plain PHPu ili bilo kojem ORMu.

Off topic: toplo preporucam sto brzi prelazak na neki Framework, ovako ces samo otegliti svoja muda, a napraviti neces bas puno.

2 Likeova

Pa sta ti jos nisi skuzio da nas covjek ■■■■■■ trolla i zajebava. Ne moguce je da netko tko radi vec godinama u ovoj struci nema bas toliko pojma, ja mislim, a polako sam i siguran, da nas covjek dobro zajebava i da se negdje iza ekrana smije ko budala kako padamo na njegove fore.

Dobro je da je siš’o sa nas i nastavio po ostalim temama prozivati sve koji koriste dokumentaciju a sve uz poslovično nemam pojma kako ovo i zašto ovo.

1 Like

Meni je isto nemoguće da netko nakon toliko godina napiše 100% false uvjet. :smiley:
Ili da to sročim tvojim riječima:

“Ti si taj uvjet napisao and ti taj uvjet nisi napisao.”

Pa niti ne moraš biti u struci, malo dijete bi skužilo da ta rečenica nema smisla. :stuck_out_tongue:
Skužilo bi dijete i u stručnom žargonu da ono tvoje nema smisla:

... AND pf.id_filt = 5 AND pf.id_filt = 7

…da je makar mjesec dana programiralo. :slight_smile:

P.S. od muhe ste napravili slona. Ovaj zadatak je totalna pizdar***, a vi bi okretali sada sve naopačke. baš lol.
Sada mi postaje jasno kako @tpojka misli sa muhom srušiti zgradu. Prvo od muhe naprvi slona…pa onda pokušaj rušenja. :smiley: :smiley:

Srećom uživam tol’ki luksuz da nikad neću morati tebe u kolegijumu imati.

Da moguce da sam se tu sjbeao i da uopce nisam do kraja procitao problem i da sam ja nesto krivo sebi protumacio, svakako se svakom desavaju i manje i vece greske, ali kao sto vidis ja nemam problem to priznati za razliku od nekih i da uopce nisam razmisljao sta pisem u toj recenici. Mea culpa i sta sad, sad ces me radi te recenice razvlacit tu po forumu zauvijek?

@trnac, s obzirom da ne radim sa nekim FW, @creatifcode me vraca na tvoj primer. Ja ga nisam uzeo u obzir, prvo sto je kod mene “Grupa / Kategorija” posebno definisana, nezavisno od ostalih atributa, vrednosti i td, a drugo sto mi se ucinilo da ima previse tabela.
Ako imas stogod slobodnog vremena, ako mozes iskljuci Grupu i napisi primer nekog upita, kako bi to izgledalo za one slucajeve koje sam naveo u postu gde su primeri mojih tabela.
Hvala!

Aaaa, ti nisi citao pitanje…pa je odjedno 100% false uvjet postao opcija. (HINT: ne moraš čitati pitanje da bi znao da x=5 AND x=7 …je nemoguće. :wink: )

Nego, što se tiče priznavanja greške i razvlačenja po forumu, mislim da si još par AND-ova i OR-ova pobrkao.
Ja sam taj koji je priznao da se najbolje ne snalazi u kopanju po dokumentacijama, pa ste me vi napali kao da sam neznam što rekao…a samo sam priznao svoju grešku. I sada ti priznaješ svoju grešku da možeš zabrljati i kada je naj od najosnovnijeg u pitanju što se tiče logičkog razmišljanja. (Temelj logičkih sklopova se zasniva upravo na jednostavnim kaskadama AND i OR uvjeta) …pa si se nešto našao uvrijeđen što te razvlačim?

Velim, pobrkao si ti malo više toga. Nisam ja došao vas razvlačiti, nego vi mene. Zgoreg je još to što to radite neutemeljeno, čega ste nesjvesni.

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

Ne, nije postao opcija i da ti budem iskren trenutno se i sam sramim sto sam to uopce napisao i pitam se kako sam uopce dosao do toga jer mi nije jasno uopce sto sam htio napisati. Mozda sam mislio na x=5 AND y=7 pa sam napravio pogresku u tipkanju, jer sam tipkao s mobitela i x i y su blizu jedan drugom, ali kao sto reko glupost napisao i ok. Rekao sam napisao sam glupost i napravio gresku, da je nisam napravio ne bih sada nesto iz te greske naucio.

Samo ti razvlaci i biljezi pogreske nemam ja s tim problem nikakav. Jebiga svatko nekad nesto bubne i ostane ziv, kako se to kod nas lijepo kaze.

Wrong, ne budem razvlačio. Samo upoznajem sugovornika da shvatim količinu njegovog znanja koji uporno mene pokušava razvlačiti :smiley: Ali ajd, ti si ok…barem znaš uvidjeti pogrešku. To se cijeni, pa makar i na ovakvom jednostavnom primjeru. Jer vidim da si nešto višlje pokušao čak opravdati taj pristup…dobro da nisi ustrajao.

Jer ima ovdje onih što pogriješe, pa ne mogu niti spoznati da griješe. I super bi bilo da iz ponosa ne žele priznati grešku, problem je što ne mogu uvidjeti da griješe…a svoje stavove brane Ad Hominem metodom.

@creatifcode, @tpojka, @trnac, @bozoou
Mislim da ce mi ovo zavrsiti posao. Jes nije po pravilima, ali sta da se radi.
Dodao sam kolonu “filteri” u tabeli proizvodi i tu smestio ID od filtera koji su dodeljeni odredjenom prozivodu. Smestio sam ih kao (550,549,553…)
Prva grupa find_in_set, ispred AND je za jednu grupu npr Čipset, a druga, iza AND, npr Format ploče
U medjuvremenu cu odraditi izmenu tabela za ovaj slucaj i sve kasnije prebaciti nekako po nekim pravilima.

SELECT *  FROM proizvodi p  WHERE 
(find_in_set(550, filteri)  or find_in_set(549, filteri)) 
 AND (find_in_set(555, filteri) or find_in_set(553, filteri)) 
 AND p.akt=1
2 Likeova

U ovome se ide korak po korak. Ako treba napraviti refaktoring nekoliko tablica, to mu je nekoliko dana posla.

Sve zavisi kako izgleda ostatak aplikacije kvalitativno i kvantitatino.

Ne kažem da je to bauk, pogotovo ako je aplikacija složena poštivajući DRY principe, onda se moduli relativno lako zamjenjuju.
Ali je ipak nelogično donositi zaključak da se nešto isplati, ako nisu poznati parametri iz kojih se procjenjuje isplativost. Ne znam, možda se oni poznaju, pa kolega tpojka ima uvid u ostatak aplikacije …u suprotnom je onakva izjava ekvivalent izjavama babe Vange.

Dovoljno bi joj bilo 7 dana da prelistava moje postove na forumu da bi bila bolji developer od tebe.