20 hours ago, kud u maglu Simoviću said:

sad ću da bupnem ko maksim po diviziji(praštajte)

gde se nalaze/angažuju unity/flutter developeri i kako to uopšte funkcioniše za pravljenje aplikacije(igrice za mobilni tipa rečko) grafički jednostavne bez neke spektakularne baze podataka

hvala

Ako je nesto sto je jednostavnije (kao sto kazes) a ti si u mogucnosti da se pozabavis time, probaj sam da napravis uz pomoc nekog AI alata (Claude Code npr). Ako dobro definises zahteve, ili ne daj boze, imas neku dokumentaciju, sasvim dobro ga mozes navoditi da ti odradi stvari kako treba.

Zalosno je koliko je optimizacija na nivou DB izumrla.

Ni solidni seniori uopste vise nemaju ovaj skill. Sve se radi na klijent strani. 😭

1 hour ago, bags said:

Zalosno je koliko je optimizacija na nivou DB izumrla.

Ni solidni seniori uopste vise nemaju ovaj skill. Sve se radi na klijent strani. 😭

Zato sto ne pisu PL/SQL code vec db code guraju u app

1 hour ago, bags said:

Zalosno je koliko je optimizacija na nivou DB izumrla.

Ni solidni seniori uopste vise nemaju ovaj skill. Sve se radi na klijent strani. 😭

Zato što je za to potrebno znanje, koje se negde napretkom hardvera zagubilo, jer nije bilo toliko potrebno... Posle su došle columnstore baze koje su to još više pojednostavile jer rade brzo, šta ćeš koji k da optimizuješ...

Pa su došle napredna SQL komande, koje ti svašta omogućavaju, pa ne moraš da misliš kako da uradiš nešto komplikovano, jer je neko to pozadiniki rešio, čime si izgubio edge...

I onda, kad treba da se nešto optimizuje, pakao...

Pričao sam negde na nekoj temi o procesima optimizcaije DB- u srpskim javnim preduzećima, jel... Poučno iskustvo...

43 minutes ago, brusli said:

Zato sto ne pisu PL/SQL code vec db code guraju u app

A ovo nije daleko od istine, jer dosta ljudi koji znaju™ sql, u dobrom delu priče stvari ne znaju da napišu komplikovaniji upit od left outer joina, i onda kad treba neki mambo jubo da se uradi sa subquerijima i slično, pakao kako napisati a da radi u realnom vremenu... Imam u firmi par ljudi koji će reći d aznaju SQL, ali kad treba neki komplikovani upit, uvek je patnja i gledanje šta i kako a da bude optimalno... Doduše kod mene je i dodatni problem što SAP ima sjajan fature™ da SQL koji ja nepišem, nije nužno onaj koji će se primeniti, i da recimo partition over nardba ne radi baš uvek isto :), ali to otom potom to su lokalni problemi...

1 hour ago, radisa said:

I onda, kad treba da se nešto optimizuje, pakao...

Jel si probao nekad da optimizujes sa AI upite u bazu?

1 hour ago, radisa said:

Zato što je za to potrebno znanje, koje se negde napretkom hardvera zagubilo, jer nije bilo toliko potrebno...

To.

Just now, Choda said:

Jel si probao nekad da optimizujes sa AI upite u bazu?

Iskreno, ja ne... Imao sma junore koji su to probili, i verujem da nije išlo jer su juniori, a ne zato što AI ne zna...

U poslednjih 2-3 godine, od kad ima AI, nisam imao tolikih problema sa samim SQL-om, da ne bih sam mogao da ispetljam, i dobijem dobre performanse, ali meni je veći problem neke stvari koje nisu direktno vezane za sam upit nego više za neke druge vidove optimizacije (paralelizacije pre svega i memory optimisation prilikom izvršenja)...Na primer, imao sam u jednom trenutku situaciji sa 40ak relativno jednostavnih upita koje stavljam u union all, i svaki se pojedinačno izvrši u mili sekundama, ali zato što engin pokušava paralelizaciju (koju na HANI ne mogu da isključim, jer što bi?)... Upit mi u celosti jede neku nenormalnu memoriju i traje 30 sekundi (tu mi je veći problem bila memorija nego vreme, ne primer)... rešenje, banalno, grupiši ih po 5, pa tih 8 viewa u union all, oda završi za sekundu i ne pojede memoriju... Da li to negd epiše? Ne...

Ili u ETLu napišem savršeno optimizovan upit koji se u debug modu izvrši u miliesekundama, ali kad pustim stavrno dobijem out of memory.. Zašto? Jer to što sam napisao, nije ono što SAP izvrši, ako nije debug mod, negio on napiše svoj upit... Onda ja gledam šta je on napisao, pa gađam kako da promenim kod da bude optimalno u tom što će on napraviti...

Mislim da razumeš, da u oakvim i sličnim situcijama, meni AI ne može baš puno pomoći...

1 hour ago, radisa said:

U poslednjih 2-3 godine, od kad ima AI, nisam imao tolikih problema sa samim SQL-om, da ne bih sam mogao da ispetljam, i dobijem dobre performanse, ali meni je veći problem neke stvari koje nisu direktno vezane za sam upit nego više za neke druge vidove optimizacije (paralelizacije pre svega i memory optimisation prilikom izvršenja)...Na primer, imao sam u jednom trenutku situaciji sa 40ak relativno jednostavnih upita koje stavljam u union all, i svaki se pojedinačno izvrši u mili sekundama, ali zato što engin pokušava paralelizaciju (koju na HANI ne mogu da isključim, jer što bi?)... Upit mi u celosti jede neku nenormalnu memoriju i traje 30 sekundi (tu mi je veći problem bila memorija nego vreme, ne primer)... rešenje, banalno, grupiši ih po 5, pa tih 8 viewa u union all, oda završi za sekundu i ne pojede memoriju... Da li to negd epiše? Ne...

Prvo sto uradimo na Oracle bazama i prod i test je da iskljucimo paralelizaciju.

Vise stete nego koristi.

Takodje dosta onih featura gde Oracle agresivno pokusava da poboljsa execution plan, odmah pogasimo.

Mogu da naprave katastrofu sto se tice performansi.

54 minutes ago, brusli said:

Prvo sto uradimo na Oracle bazama i prod i test je da iskljucimo paralelizaciju.

Vise stete nego koristi.

Takodje dosta onih featura gde Oracle agresivno pokusava da poboljsa execution plan, odmah pogasimo.

Mogu da naprave katastrofu sto se tice performansi.

Pa da...

Kod paralelizacije i tih naprednih cuda treba dosta stelovanja za svaki sistem, pojedinacno, da bi radilo kako treba... Recimo SAP za svoje aplikacije dok nisu bile na HANA bazi, trazio da paralelizacija bude iskljucena i to pise u svim notama...Mene nije mrzelo pa sam se na mnogim sistemima igrao sa podesavanjima i na kraju dobijao i po 70% ubrzanja.... Ali je trebalo imati vremena, zivaca i puno čizanja dokumentacije da bi to lepo radilo...

Kod paralelizacije (na Oraclu) imaju 3 problema:

• Proces (sesija) koja je koristi ume da uzme dosta resursa i onda druge sesije ispastaju

• Dosta Oracle bagova su vezani upravo za paralelizaciju

• Optimiser ume da napravi losiji execution plan od onog bez paralelizacije

Sve ovo vazi za kompleksne upite, direktno citanje iz tabele ili par joinova radi kako treba, sve zavisi kakva je aplikacija, ali kod ovih slozenih treba bezati od tih "naprednih" opcija.

16 minutes ago, brusli said:

Kod paralelizacije (na Oraclu) imaju 3 problema:

• Proces (sesija) koja je koristi ume da uzme dosta resursa i onda druge sesije ispastaju

• Dosta Oracle bagova su vezani upravo za paralelizaciju

• Optimiser ume da napravi losiji execution plan od onog bez paralelizacije

Sve ovo vazi za kompleksne upite, direktno citanje iz tabele ili par joinova radi kako treba, sve zavisi kakva je aplikacija, ali kod ovih slozenih treba bezati od tih "naprednih" opcija.

Slicno i na HANA samo sto ne mozes (lako, a nekad i uopste) da iskljucis paralalelizaciju...

Zaista ne vidim razlog da se apriori “beži” od paralelizma u izvršavanju kompleksnih upita koji čitaju značajne količine podataka i/ili imaju relativno visok estimated execution cost. Ok, možda je paralelizam u Oracle-u bagovit (?), ali u MSSQL-u paralelizam šljaka vrlo dobro i donosi značajne benefite kada je korektno konfigurisan.

3 minutes ago, Willow said:

Zaista ne vidim razlog da se apriori “beži” od paralelizma u izvršavanju kompleksnih upita koji čitaju značajne količine podataka i/ili imaju relativno visok estimated execution cost. Ok, možda je paralelizam u Oracle-u bagovit (?), ali u MSSQL-u paralelizam šljaka vrlo dobro i donosi značajne benefite kada je korektno konfigurisan.

Ja sma isto sa MSSQL om imao najbolje poboljšanja u paralelizaciji, ali tu sam se baš bio duboko udubio i svašta nešto tetsirao... Na njamu sam bio postigao tih 70% poboljšanja... Nismam mogao da verujem šta sma na kraju dobio i kako je funkcionisalo... Malo je reći da sam bio oduševljen...

Ali sa Oracleom smo imali situaciju, kao ovo što kaže brusli, da je bilo po defaultu isključeno, i kada smo se pojavili sa idejom da to uključimo, i iako smo pokzali zanačajan napredak u performansama (30 - 50%), ipak nem nije bilo dozvoljeno da to implementiramo i sklonjeni smo sa projekta... Na koji smo bili pozvani da rešimo problem performansi... To je bilo prošle godine...

Ne znam, ja se u posledenjih 5-6 godina, 80% vremena bavim HANA, ostalih 20% uglavnom MSSQL-om, i osim ovih HANA bubica, na koje sma se navikao, stvarno nemam nekih pretarenih problema sa performansama iako su setovi sa kojim radim milion do više milijardi slogova...

Evo malo da spamnem ovde međ profesionalcima, od poslednjeg puta kad sam spominjao da self hostujem IRC i slično, poraslo dete, osamostalilo se i sad nekoliko servisa imam spinovano na kućnoj infri, pa ako neko hoće ili može da testira, svaki feedback dobrodošao.

IRC - ima nas sada već tridesetak, većina self hosting, programatori, secops, devops, itd, sa svih strana sveta:

irc.inthemansion.com

SSL port: 6697

Glavna soba: #lobby

SearXNG meta private search engine koji koristi više različitih SE za search i agregira u čisti output, nema trackovanja, svako sebi preko cookies može da podesi kako želi search, zero knowledge:

search.inthemansion.com

I sada upravo završio isto Privatebin instancu, 10MB max upload fajlova, text ili fotke za quick share, dekripcija u browseru, zilč vidim ja na serveru, osim enkriptovanog gibberisha:

paste.inthemansion.com

Generalno, treba da updatujem sa servisima glavni sajt inthemansion.com, ali tu je ideja da bude neki gateway za private servise koje hostujem i svako dobrodošao da koristi

Hvala na pažnji!

I kratak update oko IRCa, napravih i online chat instancu, pa ako neko hoće da bane, tamo smo:

https://webirc.inthemansion.com

Sve što treba je da se klikne Connect, možda promeni nick eventualno i to je to