Pa to uopće ne sporim. Ti si enciklopedija i svatko tko uči iz enciklopedije može biti bolji developer od mene. Doduše, to i dalje ne govori da je enciklopedija bolji developer od mene. 
Ona je samo knjiga, zadržava informacije…ali ih praktično ne može upotrijebiti. 
Nego, ne reče ti što si čovjeku predložio konekciju sa bazom iz petlje?
Vjerojatno je došlo do logicke greške kao i kod mojeg x=5 and x=7.covjek jednpstavno nije razmišljao u tom trenutku
Samo što tvoja greška nema šansu da prismrdi produkciji.
I što će se loše desiti? Nema on kaskadno 1000 filtera…nego će ih imati dva, tri… ma da i 10 …
baš me zanima što će se loše desiti iz toga? 
Uvažavam stvarno neki argumentirani realni problem.
Red je valjda da napomeneš čovjeku da tako što si uradio se nikad ne radi i da je to antipattern i big no-no.
Posljednju aplikaciju koju sam radio je imala preko 100 tabela uklopljenih da ništa ne štuca i da desetke hiljada podataka vraća u par desetinki (bukvalno manje od 0.3). I kažem da se tako ne radi, i ako je to jedini način da nešto proradi onda aplikacija debelo ne valja te nikakvo vrijeme za restruktuiranje aplikacije nije greška potrošiti.
A isto tako sam skoro radio s jednim što dijeli neznanje s tobom i guess what: aplikacija mu nije mogla raditi zbog poziva baze iz foreach-a a još nije dao nanijeti da je zbog toga. Da malo bolje pričaš engleski, pomislio bi’ da si to ti bio.
Slobodno se sad pohvali nekom sopstvenom obimnijom aplikacijom gdje query iz petlje radi k’o sat. 
Njoj ne bi trebalo nista. Jer je dobivala sve informacije od demona u realnom vremenu.
Reći da je nešto big no-no nije argumentiranje i nije prikazivanje realnog problema. Sve ostalo što si napisao također nije argumentiranje…
Izuči big O. Post must be at least 20 characters
1 Like
Sjeo za komp, pa da malo rasčlanim nebuloze koje pišeš.
Tako nebitno jel app ima 100 tablica, 10 tablica ili 1000. Jedan SQL select je opterećen samo onom tablicom/tablicama na koje će se on referirati. A tu je onda samo bitno da li ta tablica/e iz koje čitamo ima 100 redaka ili 1 000 000 redaka …i da li pravilno čitamo iz te tablice, koristeći indeksirana polja i sl.
Ako čitamo istovremeno iz više tablica, isto tako da su JOIN-i povezani preko indeksiranih polja…itd.
Kako god, ova tvoja izjava je ravna izjavi:
“Imam web sa 1 000 000 slika, a učitava se za 0.3 sekunde”
…a zaboravio si napomenuti da učitavaš podstranicu koja nema uključenu niti jednu sliku na sebi, hehe. …ili je svaki tvoj SQL upit čitao istovremeno iz svih 100 tabela?
Svaki normalan/običan app to može … nikakva nauka. Ovime ništa nisi rekao o težini strukture podataka iz kojih se to čitalo 
…a još manje se ovime referiraš na konkretan problem o kojem pričamo.
Opet ti zaboravljaš iz čega se vadi isplativost određenih zahvata. Da ti nacrtam…
Što ako imaš app koji zarađuje 10kn/mj …vrlo vjerovatno će se ugasiti za godinu dana ako sunce nekim čudom ne svane. Želiš dodati jedan filter, moraš eto jer te klijent vuće za rukav, a želiš opravdati obraz i udovoljti klijentu, mada znaš da taj zahvat nema smisla…kada se ionako web uskoro gasi.
I imaš sljedeće solucije:
- postoji full-full-dirty način da se to ugradi u pola sata (ali će radit)…
- i postoji full-profi način da se to ugradi, ali koštat će 50 sati posla. Unatoč profi pristupu ispod haube, na van će raditi gotovo isto.
Što odabrati?
Da ne bude zabune, ovdje ne apeliram niti da je takav web od pokretača teme…niti da je SQL unutar foreach full-full-dirty pristup…samo uvodim u računicu sve krajnosti da postane očigledno iz čega se procjenjuje isplativnost nekog zahvata. Pošto vidim da to ne možeš shvatiti. Btw. zadnji pokušaj što se toga tiče.
Još kada bi znao argumentirati i zašto mu nije radila zbog poziva iz foreacha?
Pa naravno ako u SQL staviš x=5 and x=7 da neće raditi, zvao ti iz foreacha ili kako god. Bez mogućnosti da argumentiraš zašto ne zvati iz foreacha, sve drugo je lupetanje.
…
…
A sada malo logike i argumenata.
Da ne zaboravimo, tema je argumentirati zašto DA i zašto NE SQL query u foreach petlju. A ne lupetanje o tome što si radio i što nisi radio.
- Kaskadno zvati više SQL query-a za redom ili zvati SQL query iz foreach petlje je isti vrag!
- Kaskadni poziv SQL query-a nije ništa čudno, nikakav bauk. To je najuobičajnija procedura ako se stvar ne može obaviti unutar jednog query-a.
- Samo treba biti svjestan prednosti/mana kaskadnog query-a da se vidi da li u konkretnom primjeru ima smisla
- Npr. problem novčane transakcije. Ako imaš više kaskadnih query-a gdje sa jednim query-em nekom skidaš novac sa računa, a drugim query-em nekom dodaješ novac na račun …moraš biti svjestan da između ta dva query-a može doći do prekida rada, ako iz bilo kojeg razloga baza pukne. Može npr. nestati struje i proces se neće do kraja završiti. A nikako ne želimo da prvi kaskadni query skine nekom novac sa računa, te da zbog prekida rada servera taj novac ne sjedne nekom drugome na račun. U tu svrhu je izmišljen BEGIN i COMIT, što će reći da će se svi procesi na bazi poništiti nakon BEGIN-a, ako COMIT nije konfirmao kraj kaskadnih procesa. Što će reći da se nebi izmislio BEGIN i COMIT, da kaskadni queryi nisu svakodnevno u upotrebi.
- Što se tiče razlike između kaskadnog query-a i query-a iz foreach petlje. Pa nema značajne razlike, osim što foreach petljom možeš natjerati cca 1 000 000 kaskadnih query-a, a dok ih pišeš ručno, vrlo teško da ćeš ih nakucati toliko.
- No, gdje je uopće problem, zašto ne 1 000 000 kaskadnih querya? Što se gubi pozivanjem više querya, ako je već sve stalo u jedan query?
Za odgovor na to pitanje, treba rasčlaniti koji utrošak vremena radi svaki individualni query.
- Priprema query-a - svaki SQL query se treba razumjeti/parsirati od SQL enginea.
- Dohvaćanje podataka
Što se tiče pripreme querya. To je proces da računalo obradi string SQL query-a i da shvati koji zadatak taj query nosi u sebi. Obrada SQL stringa nije neki zahtjevan zadatak i kreće se reda veličine 0.1ms, tj. računalo može obraditi cca 10 SQL query-a untuar samo jedne milisekunde…ili 10 000 SQL querya unutar sekunde.
Pričamo o prosjeku, naravno duži SQL query treba nešto više vremena da se obradi.
Kada pričamo o kaskadi, ako natjeramo računalo da obavi isti zadatak unutar dva query-a što je moglo ići sa jednim, onda smo izgubili duplo više vremena na pripremu query-a.
(Ne baš duplo više, jer realno ako smo dva kaskadna query-a strpali u jedan query …onda taj jedan query postaje nešto duži i tako nešto teže obradiv. Ali možemo aproksimirati da za dvija query-a nam treba duplo više vremena) No koliko je to više vremena? Ako jedna obrada traje 0.1ms, izgubiti dodatnih 0.1ms, što nije nikakav bauk ako uzmemo da se prosječna stranica učitava reda veličine >100ms.
Naravno, ako natjeramo računalo na 100 query-a gdje je sve moglo opisati jednim, onda smo izgubili dragocjenih 10ms. (Iako je i to granica prihvatljivosti za mnoge)
Što se tiče konkretnog problema pokretača teme, ne vidim da ima 100 hijerarhijskih filtera u dubinu, niti je opis problema takav da će ih ikada imati. Može imati maksimalno do 10 filtera u kaskadi, što znači da bi žrtvovao samo 1ms. Ako žrtva ima smisla, ako pojednostavljuje problem…to je baš nikakva žrtva. Apsolutno zanemariva.
Osim utroška vremena na pripremu query-a, imamo naravno utrošak vremena i na samo dohvaćanje podataka iz baze (točka 2). Računalo mora u bazi pronaći podatak koji selektiramo i vratiti nam ga.
Taj utrošak vremena ovisi ponajviše o veličini tablice iz koje dohvaćamo podatak. Računalu nije isto ako tablica ima 10 redaka ili 1 000 000 redaka. (Ali mu je svakako poprilično nebitno da li imaš u aplikaciji 10 tablica ili 1000 tablica ) …kada se ono bakće samo sa onom tablicom/cama iz koje se dohvaćaju podaci.
U najprimitivnijem smislu računalo mora proći kroz svaki redak tablice, usporediti vrijednosti retka sa uvjetom iz SQL query-a, te ako uvjet zadovoljava…vraća nam podatke iz tog retka.
Više redaka, više potrebnog vremena da nam pronađe ono što trebamo. Inžinjeri baza naravno nisu stali nad tim primitivnim pretraživanjem, pa su uveli indexe. Indexi omogućavaju binarno pretraživanje tablica, što će reći da je podatak dohvatljiv računalu u broj koraka → slikovito:
Korak 1: 2
Korak 2: 4
Korak 3: 8
Korak 4: 16
Korak 5: 32
Korak 6: 64
Korak 7: 128
Korak 8: 256
Korak 9: 512
Korak 10: 1024
…
Korak 30: 1 073 741 824
Znači,
minimalno 4 koraka su računalu potrebna da pronađe podatak ukoliko imamo 16 redaka u tablici
minimalno 10 koraka mu je potrebno ako imamo 1024 retka
i minimalno 30 koraka mu je potrebno ako imamo milijardu redaka.
Tu vidimo veliku prednost indeksiranog / binarnog pretraživanja, jer broj redaka u tablici nam može drastično narasti, a broj potrebnih koraka računala da se pretraže ti retci raste eksponencijalno sporije.
No to i nije tema, jer kako god, svaki taj korak pretraživanja košta vremena…a ako pričamo o usporedbi kaskadnog query-a i trpanjem svega u jedan query, trebamo biti svjesni na koliko ćemo pretraživanja natjerati računalo (Bilo indeksiranih ili običnih), i što nam to donosi za neku konretnu situaciju.
Recimo tri kaskadna query-a:
"SELECT * FROM table WHERE ID=5214"
"SELECT * FROM table WHERE ID=1054"
"SELECT * FROM table WHERE ID=9985"
će trigirati tri pretraživanja po polju ID. Dok jedan query koji zamjenjuje gornja tri:
“SELECT * FROM table WHERE ID in (5214, 1054, 9985)”
će natjerati računalo na samo jedno pretraživanje po polju ID.
S druge strane, tri kaskadna query-a:
"SELECT * FROM table**1** WHERE id=5214"
"SELECT * FROM table**2** WHERE id=1054"
"SELECT * FROM table**3** WHERE id=9985"
će trigirati tri pretraživanja, ali ako to isto strpamo u jedan query, opet ćemo imati tri pretraživanja…jer se ionako radi o različita tri polja po kojima se pretražuje.
I sada da se vratimo na konretan problem iz ove teme.
Pokretač teme ako pribjegne kaskadi, gubi:
- manje od 0.3ms na dodatnu pripremu SQL kaskadnih query-a
- cca 1ms duži dohvat podataka. (Pogađam da je to 1ms, svakako taj red veličine, ako ne i manje. Jer nezgodno je pogađati i za single query na koliko pretraživanja će natjerati SQL engine. Nekada se čini da će SQL engine to znati u jednom šusu napraviti, ali ne bude uvijek tako)
Postoje tehnike da se provjeri koliko je bilo pretraživanja (nezz kako točno to ide) …ali u praktičnoj primjeni je sve još jednostavnije, a glasi: “Ako nema zagušenja, nema ni problema”
Tamo gdje su tablice do 1000 polja, sigurno neće biti zagušenja. 
…a sumnjam da rad sa filterima zahtjeva tablice od nekoliko desetaka tisuća redova. (A ni te nebi bile problematične)
Isplativost?
Pa ako je pokretaču teme cilj unaprijediti svoje znanje, zašto ne picajlizirati.
Ako unaprijeđuje strukturu stranice za neke velike naknadne updejtove …želi pojačati temelje za dalje… zašto ne picajlizirati.
Ali ako treba rješiti samo ovaj problem sa što jeftinijim utroškom vremena, sigurno se neće zamarati sa rekonstruiranjem baze radi uštede od jedne milisekunde, hehe.
No ovdje pričamo o manama kaskadnog query-a, gdje vidimo da za konkretnu situaciju ih zapravo niti nema.
1 Like
Momci, bespotrebno ste zabrijali krivim smjerom. Znate li koliko ste koda mogli naštrikati za to vrijeme?
Neko štrika. A neko lupa da ne zna gdje mu je dupe a gdje glava.
Vidiš da čovjek nema uopšte apstrakciju kakva je aplikacija koja ima sortirano 1000 tabela.
E’ da mi je vidjeti klupko koje je ostavio ovima što su ga šutnuli, platio bi’ ručak u lokalu po želji.
Mislim da bi mi to bilo u nivou k’o kad klinac vidi bradatu ženu u cirkusu.
Još jednom, početnicima: uzimajte @bozoou -ove savjete sa 3 debele kašike soli - apsolutno sve što priča gubi smisao i ne vodi se nikakvim principima programiranja. Po ovome što piše, biće prije da je do nedavno popravlj’o kišobrane. Ne vjerujte ni meni isto tako. Uporedite sve što pročitate ovde na forumu sa zvaničnom dokumentacijom i uvijek se pitajte je l’ to što radite dobro i da li može bolje.
A vodilja neka vam bude dostizanje industrijskog standarda u svakom segmentu.
Edit: malo je ljudi koji mogu da vas nauče nešto i poslušajte savjete @creatifcode i @tony (i to ne samo PHP, čitajući ih već prvenstveno sa strane koncepta i dobre prakse) kad naidjete na temama. To bi’ naslijepo mog’o da kažem da nećete pogriješiti u tome. Vjerovatno još neke. Al’ definitivno @bozoou -ove postove ukol’ko ne možete preskočiti (znam, i meni su zanimljivi sa fenomenološkog aspekta) uzmite sa 3 debele kašike soli.
To se zovu transakcije na bazi.
Koriste se kroz transakcije, kad imas select, pa update ili insert itd.
Ako imas samo select, onda se sve moze napraviti u jednom query-u.
Ako se arhitektura napravi kako treba, koristilo se DI/DIC i ostale moderne stvari ili ne, bilo kakva izmjena zahtijeva jako malo vremena, npr. dodavanje filtera, polja i sl.
Od tebe nikada argumenata, samo Ad hominem.
I svaki puta se u to isponova uvjerim kada uđem sa tobom u neku raspravu. Kada si tako strogo popljuvao SQL unutar foreacha, stvarno sam se nadao nekoj argumentiranoj opasci da nešto naučim novo. A do tebe dobijem samo odgovore u stilu: “Trla baba lan…da joj prođe dan…”
Ako može, sve štima. Niti ne tvrdim da se ne može.
Ako u nekoj određenoj situaciji nekome može biti lakše kaskadom (jer eto ne zna napisati single query)…ne vidim nikakav big problem.
Ako sumnjam da je problem, onda ću si uvijek rasčlaniti sve argumente ZA i argumente PROTIV, pa odvagnuti jel se isplati.
Al govoriti nešto strogo NE, bez vaganja argumenata, i općenito bez iznošenja negativnih argumenata …je glupost.
Misli šta 'oćeš. Znamo i ti i ja (a i ostali pratioci foruma) ko’lko [ni]sam u pravu.
1 Like
Toliko je teško stati argumentima iza svojih tvrdnji? Jer to ti je sve dalje Ad hominem.
Ja ti se kunem da sam ti čak povjerovao da se tu krije neka teška opasnost koje nisam bio svjestan i htio sam baš čuti koja je. Naučiti nešto novo.
…ali bit će da si samo u fazonu kenjanja bez obrazloženja. Doduše, nije čudan mode za tebe. (kada razgovaraš samnom)
Onaj tko to ne zna, a moze se nesto odraditi u jednom query-u, onda nije za taj posao.
Ovo je zrelo za novi topic, filozofske rasprave o sql-u.
Kak’ vam se da toliko drobiti??? Respect momci
1 Like
Pa ovdje si imao situaciju da nitko nije znao strpati sve u single query dok pokretač teme sam to nije iskopao. Kaj sad, nitko ovdje nije za taj posao? Lupaš ga i ti i ostaneš živ.
I opće me briga jel netko zna ili ne zna strpati sve u jedan query …samo analiziram razloge protiv kaskadnih query-a. Tko zna pisati single query, pisat će ga. Tko ne zna, ok je da zna što time žrtvuje. Ako se ništa bitno ne žrtvuje za određenu situaciju, nije big deal.