Sve krece od arhitekture baze.
Ako je arhitektura jako losa, onda si pusiona u startu.
Šta sam im’o u vezi ove teme, ja sam i rek’o.
+1
1 Like
Što si imao to si rekao…a rekao si ti i što nisi imao.
Ja obično ako nešto popljuvam, imam obraza stati argumentima iza onoga što popljuvam.
Ti ako si već popljuvao kaskadni SQL query … od imalo korektnog sugovornika bi dobio obrazloženje njegovog stajališta…a ne da podvuće rep i napada Ad hominem pristupom.
Al dobro, ni prvi puta, vjerovatno ni zadnji puta dobih to od tebe. Čini se da si stvarno rekao sve što imaš. Tako da odoh i ja sa ove teme. 
Dodjem pivo. Post must be at least 20 characters
A kako aplikacija komunicira sa DB serverom ? Je l’ putem mreze (networka) ?
Nisam DB ekspert, zanima me cisto kako bi slozio neku svoju teoriju zasto query u petlji nije najsretnije rijesenje 
Bravo, dobra opaska. Ako se radi o remote bazi, onda imamo i dodatni ping time po svakom queryu.
Osobno, ako bi morao ubaciti jednu dvije kaskade i ako će mi to pojednostaviti nategnuti query, nebi smatrao niti taj dodatni ping time nekim problemom.
Kao što rekoh, sve zavisi od situacije. Velika je razlika jel u konretnom slučaju idemo na 2-3 kaskade, ili se tim pristupom riješava problem gdje je potrebno 100 - 1000 kaskada, što je onda svakako nepoželjno.
P.S. nezz jel upitnik bio radi reda, ili stvarno pitanje. Ako je slučajno bilo pitanje, onda imaš varijante:
- remote databse - baza je udaljena na nekom drugom serveru, komunikacije preko networka, pojavljuje se delay u komunikaciji (ili ti ping time)
- local database - baza je na istom serveru, komunikacija je direktna. Ne postoji ping time.
Large numbers of queries can cripple web applications and bring them to a grinding halt. With enough data in the tables or enough people accessing this script at once everything will start getting very slow very quickly.
Ok, ako smo sigurni da ce velicina liste biti 2-3 vjerovatno nece stvarati ogroman problem, e sad je pitanje da li smo sigurni u to
Ovo ne bi trebalo biti najsretnije rijesenje pogotovo ne za aplikacije koje imaju veci load tako da u vecini slucajeva baza na drugom serveru bi trebala biti pozeljnija opcija - kako zbog performansi, tako i zbog sigurnosti.
@tpojka thnx upoznat sam sa nekim osnovama Big-O notacije, bacim pogled na ovo
Koliko sam ja shvatio zadatak postavljača teme, situacija je takva. Da ima i puno više filtera u hijerarhiji u dubinu nego što je prosjek za takav tip stranice, i dalje nebi bilo osjetne razlike.
Ovo je sada već druga tema… iskreno se nisam zamarao tim pitanjem.
Ne kara majka Muju što kocka.
Ovo vjerovatno je tu s razlogom
Broj requestova neće promjeniti omjer uštede nekasnadnog query-a nad kaskadnim. Ako smo već izračunali da kaskadni query žrtvuje u ovom slučaju red veličine 1ms, onda je to i dalje utrošena 1ms.
A to što će 1000 requestova tu 1ms pretvoriti u 1s, to je drugi par opanaka.
Već smo rekli da je prosječan load stranice reda veličine 100ms, znači da će tih 1000 requestova onda samo na loadu opteretiti server za 100 sekudni.
Tako da ako već postoji zagušenje radi velikog broj requestova, onda se optimizira od tamo gdje najviše curi…a ne gdje curi 1ms radi kaskade.
Al dobro, ne tvrdim ja da ne treba uvijek razmišljati o optimizaciji svega. Naravno da treba. Zato moj savjet i je bio pokretaču teme da optimizira sebi život, tj. optimizira uloženo vrijeme i da ni u ludilu ne radi rekonstrukciju baze radi ovakve pizda*rije od zadačića. Koliko vidim, dovoljno je pametan da je i sam to shvatio…a najbolje zna što mu se isplati u nj. koži radit.
A sada sam stvarno out ove teme. 
Tko je mogao shvatiti, shvatio je.
…
P.S. nadam se da ljudi koji nisu bili u stanju argumentirati niti nakon što ih se moli na koljenima …neće niti tražiti argumente. Pogotovo nakon što sam se isključio iz teme.
310 i 110 ne pravi neku razliku
Ali magnitudno
3500 i 1500 je razlika
To se mora ima na umu. To je upravo posljednji momenat kad se ima vremena razmišljati o big o notaciji.
Ne znam što ne bi’ pomislio da online prodavnica neće imati pristojan broj korisnika/klijenata.
Ne radi se o admin dashboard-u gdje se na neke stvari može katkad zažmiriti (nije da bi trebalo) al’ direktno stavljati najgrdju moguću opciju tamo gdje se očekuje najveći mogući promet nije sjajno.
Kud se nije ni ispostavilo da je rješenje. A već je princip u startu bio pogrešan.
Probaj da zamisliš [barem] 100 ljudi istovremeno kako se igra filterima. A ustvari se ni ne igra već real time pretražuju bazu.
Iskreno, volio bi’ čuti kako je završilo testiranje i kako se ponaša aplikacija i ako nije i ako jeste radjena rekonstrukcija tabela.
Za početak prestani govoriti kaskada i proguglaj razliku izmedju kaskade i iteracije.
Možeš li ovo potkrijepiti nekim dokazom odnosno testom (cijenim da se ostatak posta vodi ovim k’o premisom pa ću pročitati nakon odgovora na pitanje)?
Edit: 3 debele kašike soli
Nije točno.
Pogledaj
Nasao sam testove gdje navode da postgresql na serveru sa 64 cores i ne znam koliko gb rama može vrtiti 200 k selectova i 20 k zapisa u s.
@tpojka, koliko bi koštalo da mi napraviš strukturu 4, 5 tabela, za ovaj slučaj, sa izlistavanjem proizvoda i i filterom u sidebar u kojem će za svaku stavku filtera da prikaže koliko proizvoda će se prikazati izborom odredjene stavke filtera?
Naravno, ti brojevi u stavkama filtera se menjaju, u zavisnosti od prethodno cekiranih drugih stavki filtera.
Backend nije potreban.
Napiši mi u PM tačan zahtjev, odnosno kako je aplikacija zamišljena, šta sve ima, šta sve mora, bez čega ne smije, šta se očekuje… - kompletan business request.
Odgovoriću tamo.
Ne mogu ti pisati private poruke, verovatno sto nisam VIP.
1 Like
Odgovorio, hvala. Post must be at least 20 characters
@drmko jesi li probao upit koji sam ti poslao?
SELECT DISTINCT p.naziv
FROM pro_filters pf, proizvodi p
WHERE pf.id_pro = p.id
AND pf.id_filt = 3 – prvi atribut
AND p.id IN (SELECT id_pro FROM pro_filters WHERE id_filt = 6)
1 Like