Reporting je uvek bolje i performantniji na bazi, po meni... A aplikacija da bude samo interface...

Sve ostalo bih bežao od baze kao đavo od krsta...

ALi ja se bavim reportingom, nisam relevantan, toliko, za diskusiju... :)

Nadam se da ne misliš na reporting na transakcionoj bazi

Just now, Sammael said:

Nadam se da ne misliš na reporting na transakcionoj bazi

Naravno da ne...

Govorim od datawarehosima i sličnim stvarima...

Mada, SAP je krenuo da gura to i na transakcionoj, jer HANA... Napišešeš neki SQL, pozoveš ga iz aplikativnog sloja i samo ga objavi na ekranu...

@brusli današnji sistemi su distribuirani i heterogeni. Biznis logika za neku složeniju operaciju se možda nalazi u 10 različitih specijalizovanih sistema. Nema nikakve logike trpati to u bazu - nit je prirodno, nit je skladu sa standardima, nit je skalabilno.

Primer - underwriting u osiguranju. Mora da zove KYC, PEP, FATCA, banke, kreditni biro, medicinske servise... da bi dobio sve loadinge koje onda underwriter može ručno da modifikuje.

Ako vuces preko mreze samo podatke, a na racunaru imas forme i reporte tj. klijentsku aplikaciju to se raditi fenomenalno.

Sa druge strane, sa dinamickim formama i reportima i podacima - imas lepi forum sa kilavim odzivom.

Naci balans izmedju ta 2 pristupa i sacuvati zivce da se ne iznaspominjes mitohondrijalnog porekla obema stranama kad pocnu da se svadjaju je kljuc dugog zivota i mira u dusi..

Ohmmmmmm.

41 minutes ago, Sammael said:

@brusli današnji sistemi su distribuirani i heterogeni. Biznis logika za neku složeniju operaciju se možda nalazi u 10 različitih specijalizovanih sistema. Nema nikakve logike trpati to u bazu - nit je prirodno, nit je skladu sa standardima, nit je skalabilno.

Primer - underwriting u osiguranju. Mora da zove KYC, PEP, FATCA, banke, kreditni biro, medicinske servise... da bi dobio sve loadinge koje onda underwriter može ručno da modifikuje.

Sve je to lepo dok se ne dodje do distribuiranih transakcija.

Evo kod mene u firmi su probali da razbiju monolit koji je slozena ebanking aplikacija sa gomilom tabela i medjusobnih konekcija, izgubili par godina i brdo para i odustali.

Naravno baza je na Oraclu, hteli i da ponude klijentima da mogu da izaberu bazu, tj Postgresql ili Mysql, i to se zavrsilo neslavno, doduse to je puklo odmah u pocetku, pa nije izgubljeno previse para i vremena.

Edited November 20, 2025Nov 20 by brusli

2 minutes ago, brusli said:

Sve je to lepo dok se ne dodje do distribuiranih transakcija.

Evo kod mene u firmi su probali da razbiju monolit koji je slozena ebanking aplikacija sa gomilom tabela i medjusobnih konekcija, izgubili par godina i brdo para i odustali.

Naravno baza je na Oraclu, hteli i da ponude klijentima da mogu da izaberu bazu, tj Postgresql ili Mysql, i to se zavrsilo neslavno, doduse to je puklo odmah u pocetku, pa nije izgubljeno previse para i vremena.

Cekaj, kako su zamislili da pristupaju bazi za ebanking?

i iz cega?

Ima java aplikacija koja se konektuje na bazu.

Edited November 20, 2025Nov 20 by brusli

3 hours ago, bags said:

@brusli

Pitanje je opet da li je to pametno. tj. treba izbegavati koliko god je moguce.

Ja ne znam nikoga ko je rekao bas super sto cu da se igram sa PLSQL-om .

Ja sam se školovao na Peleskuelu^tm

U teoriji je meni to bilo super zanimljivo, a u praksi sam posle radio neke sisteme za osiguravajuće kuće i pobegao na web glavom bez obzira. Bože sačuvaj čega je tu sve bilo, normalizacija baze podataka je očigledno jedan koncept koji pročitaš, presaviješ i sakriješ ispod tepiha. Plus radiš u onim jbnim Formsima, viđao sam čelične konstrukcije koje su fleksibilnije od Oracle Formsa.

2 hours ago, brusli said:

Za ostale se ne slazem .

Ovo sve vazi za slozene app, sa gomilom relacija i joinova i sa slozenom biznis logikom sa mnogo koraka, za ove jednostavne moze i postgresql/mysql.

1. PL/SQL sam koristio poslednji put pre 15 god, pgSQL koji ima dosta bolju sintaksu sam koristio za reporting pre 5 godina. Oba su apsolutno inferiorni u odnosu na Javu iz 90tih da ne govorim o modernim verzijama Kotlina, C#, Typescripta i Pythona.

2. O refactoring izvan nekog search/replace je isto iluzorno pricati. Pocev od nedostatka bazicnih stvari poput Extract to method i Find Usages, preko promene parametara do recimo masovnih promena u kodu poput necega sto radi Moderna sa Javom ili Angular sa schematics. Naravno to je i zato sto je jezik puno vise vezan za same db strukture i sto ima primitivne konstrukte.

3. Testiranje je milion puta teze zbog implicitnih stvari poput trigera, zbog uticaja na same podataka, otezan mockup itd itd.

4. Java debugging je sa druge planete za PL/SLQ. Remote debugging, pomeranje u vremenu (napred nazad u toku seanse), promena vrednosti varijabli (hotswap), duboka inspekcija, watches u multi concurrency modu, logika za komplikovane breakpointe, memory profiling.

5. Da li tvoj tim ima sav PL/SQL code u gitu? :P Ja sam samo jednom sreo MLSQL db admina koji je imao sve artefakte u gitu.

6. Code sharing je na velikim projektima i medju timova teska prica. Ja nisam siguran da PLSQL uopste ima neki centralni package manager.

7. Ovo mozda i nije tacno. Generalno tesko je naci kvalitetne DB developere a oni sto su dugo u firmama i poznaju sisteme dobro neretko koriste ucenjivacki potencijal.

2 hours ago, brusli said:

A prednost logike na bazi je sto je kod mnogo cistiji i logicniji, kada vidim ono hibernate djubre bude mi muka.

Svaki standardan ORM ima i native queries mogucnost gde mozes pisati potpuno cist SQL.

Sigurno postoje timovi koji ne gledaju sta njihov ORM generise i salje na bazu, ali Hibernate sasvim korektno radi posao ako znas iole da ga koristis (N+1 je tipicno pitanje za juniore) i ako gledas sta salje na bazu.

2 hours ago, brusli said:

Da ne govorim ako pozivas nesto iz baze pa vuces rezultat na app, obradjujes pa saljes ponovo na bazu itd, koliko je sporije, nego ako je sve interno na bazi.

Ovo je prilicno subjektivno. Vecini ljudi je PL/SQL jako tesko citljiv usled nedostatka mnogih elegantnih feature-a.

Za ogromne kolicine podataka sigurno je korisno kad podatke obradjujes direktno u bazi, ali na drugoj strani imas puno veci scale i elegantiji code ako radis u Javi.

Npr. batch jobovi u Javi/Python trivijalno izvrse particionisanje podataka, multithreading processing i ponovno pisanje u bazu. Plus mozes beskonacno skalirati dok takav luksuz nemas na DB serveru ako nista ono zbog ogranicavajucih licenci.

Za full text search je ES odavno pobedio ove integrisane u bazama.

2 hours ago, brusli said:

Takodje kompajliranje PL/SQL odmah ti pokaze gresku, a sa app moras da probas da izvrsis, pa onda gledas gde je problem itd.

Moderni IDE za Javu cak ne mora ni da ti kompajlira code da bi dobio odlicnu staticku analizu.

Java kompajler ce ti ponuditi puno veci safe net nego PL/SQL.

Na sve to da bi video da li tvoj code zaista radi ti ga moras izvrsiti i sa PL/SQL i sa Javom.

1 hour ago, Sammael said:

@brusli današnji sistemi su distribuirani i heterogeni. Biznis logika za neku složeniju operaciju se možda nalazi u 10 različitih specijalizovanih sistema. Nema nikakve logike trpati to u bazu - nit je prirodno, nit je skladu sa standardima, nit je skalabilno.

Primer - underwriting u osiguranju. Mora da zove KYC, PEP, FATCA, banke, kreditni biro, medicinske servise... da bi dobio sve loadinge koje onda underwriter može ručno da modifikuje.

Tacno. Ovo je danasnja realnost. Pre si imao jednu centralnu bazu i onda si vertikalno skalirao po potrebi.

Sada imas cak i obicnim redovnim firmama desetine izvora podataka od relacionih baza, objektnih baza, raznih MQ, Rest API, third party auth sistema.

Ja zaista ne vidim nacin na kojim se preko PL/SQL moze zalepiti sve to. Jedino zaista da imas sistem koji sve to skuplja i gura u jednu centralnu bazu sto je u medjuvremenu zaista anti-pattern i veliki riziko. Naravno osim ako je slucaj kao u ovom tvom postu ispod gde je baza organski narasla.

32 minutes ago, brusli said:

Sve je to lepo dok se ne dodje do distribuiranih transakcija.

https://www.vldb.org/pvldb/vol10/p685-zamanian.pdf/ (2017)

32 minutes ago, brusli said:

Evo kod mene u firmi su probali da razbiju monolit koji je slozena ebanking aplikacija sa gomilom tabela i medjusobnih konekcija, izgubili par godina i brdo para i odustali.

Naravno baza je na Oraclu, hteli i da ponude klijentima da mogu da izaberu bazu, tj Postgresql ili Mysql, i to se zavrsilo neslavno, doduse to je puklo odmah u pocetku, pa nije izgubljeno previse para i vremena.

Tesko je znati bez mnogo vise detalja gde nastao problem. Dosta modernih banaka (N26, Monzo, Revolut i sl.) su napravili arhitekture koje im omogucavaju da koriste PostgreSQL/MySQL. Ako su vec imali u nekoj verziji ogromnu centralnu bazu ne mozes samo adaotirati SQL,preci direktno na jednu od ove dve i nastaviti sve po starom. Imas odredjene nacine kako zaobici standardne probleme (CQRS, agresivan caching, messaging queues, saga pattern izmedju ostalih) a koji su na srecu poslednjih 10ak godina odlicno dokumentovani recimo na blogovima od ovih velikih tech firmi.

1 hour ago, bags said:

1. PL/SQL sam koristio poslednji put pre 15 god, pgSQL koji ima dosta bolju sintaksu sam koristio za reporting pre 5 godina. Oba su apsolutno inferiorni u odnosu na Javu iz 90tih da ne govorim o modernim verzijama Kotlina, C#, Typescripta i Pythona.

2. O refactoring izvan nekog search/replace je isto iluzorno pricati. Pocev od nedostatka bazicnih stvari poput Extract to method i Find Usages, preko promene parametara do recimo masovnih promena u kodu poput necega sto radi Moderna sa Javom ili Angular sa schematics. Naravno to je i zato sto je jezik puno vise vezan za same db strukture i sto ima primitivne konstrukte.

3. Testiranje je milion puta teze zbog implicitnih stvari poput trigera, zbog uticaja na same podataka, otezan mockup itd itd.

4. Java debugging je sa druge planete za PL/SLQ. Remote debugging, pomeranje u vremenu (napred nazad u toku seanse), promena vrednosti varijabli (hotswap), duboka inspekcija, watches u multi concurrency modu, logika za komplikovane breakpointe, memory profiling.

5. Da li tvoj tim ima sav PL/SQL code u gitu? :P Ja sam samo jednom sreo MLSQL db admina koji je imao sve artefakte u gitu.

6. Code sharing je na velikim projektima i medju timova teska prica. Ja nisam siguran da PLSQL uopste ima neki centralni package manager.

7. Ovo mozda i nije tacno. Generalno tesko je naci kvalitetne DB developere a oni sto su dugo u firmama i poznaju sisteme dobro neretko koriste ucenjivacki potencijal.

Svaki standardan ORM ima i native queries mogucnost gde mozes pisati potpuno cist SQL.

Sigurno postoje timovi koji ne gledaju sta njihov ORM generise i salje na bazu, ali Hibernate sasvim korektno radi posao ako znas iole da ga koristis (N+1 je tipicno pitanje za juniore) i ako gledas sta salje na bazu.

Ovo je prilicno subjektivno. Vecini ljudi je PL/SQL jako tesko citljiv usled nedostatka mnogih elegantnih feature-a.

Za ogromne kolicine podataka sigurno je korisno kad podatke obradjujes direktno u bazi, ali na drugoj strani imas puno veci scale i elegantiji code ako radis u Javi.

Npr. batch jobovi u Javi/Python trivijalno izvrse particionisanje podataka, multithreading processing i ponovno pisanje u bazu. Plus mozes beskonacno skalirati dok takav luksuz nemas na DB serveru ako nista ono zbog ogranicavajucih licenci.

Za full text search je ES odavno pobedio ove integrisane u bazama.

Moderni IDE za Javu cak ne mora ni da ti kompajlira code da bi dobio odlicnu staticku analizu.

Java kompajler ce ti ponuditi puno veci safe net nego PL/SQL.

Na sve to da bi video da li tvoj code zaista radi ti ga moras izvrsiti i sa PL/SQL i sa Javom.

Tacno. Ovo je danasnja realnost. Pre si imao jednu centralnu bazu i onda si vertikalno skalirao po potrebi.

Sada imas cak i obicnim redovnim firmama desetine izvora podataka od relacionih baza, objektnih baza, raznih MQ, Rest API, third party auth sistema.

Ja zaista ne vidim nacin na kojim se preko PL/SQL moze zalepiti sve to. Jedino zaista da imas sistem koji sve to skuplja i gura u jednu centralnu bazu sto je u medjuvremenu zaista anti-pattern i veliki riziko. Naravno osim ako je slucaj kao u ovom tvom postu ispod gde je baza organski narasla.

https://www.vldb.org/pvldb/vol10/p685-zamanian.pdf/ (2017)

Tesko je znati bez mnogo vise detalja gde nastao problem. Dosta modernih banaka (N26, Monzo, Revolut i sl.) su napravili arhitekture koje im omogucavaju da koriste PostgreSQL/MySQL. Ako su vec imali u nekoj verziji ogromnu centralnu bazu ne mozes samo adaotirati SQL,preci direktno na jednu od ove dve i nastaviti sve po starom. Imas odredjene nacine kako zaobici standardne probleme (CQRS, agresivan caching, messaging queues, saga pattern izmedju ostalih) a koji su na srecu poslednjih 10ak godina odlicno dokumentovani recimo na blogovima od ovih velikih tech firmi.

Radio sam i PL/SQL, a nedavno i u paraleli dva projekta gde na jednom nisam imao mogucnost Java debugginga(NetSuite Oracle ERP). Da moram ponovo to da radim to bi mi razlog za otkaz. Patnja.

Biznis logika u bazi, veliki no-no. Već objašnjeno ovdje zašto.

5 hours ago, bags said:

1. Da li tvoj tim ima sav PL/SQL code u gitu? :P Ja sam samo jednom sreo MLSQL db admina koji je imao sve artefakte u gitu.

2. Code sharing je na velikim projektima i medju timova teska prica. Ja nisam siguran da PLSQL uopste ima neki centralni package manager.

Naravno da imamo PL/SQL code u GIT-u, ne vidim sto ne bi imali.

Sa tim je povezana i ova druga stavka.

Za ostale tacke nisam bas sve razumeo, jer nisam radio sa njima, ali citljivost koda u PL/SQL-u i citljivost Jave, dajte ljudi nemojmo se zaebavati

PL/SQL se i ne koristi za reporting, vec za obradu podataka, tj DML.

Naravno u toku obrade, mozes procitati podatke kako hoces, i meni je bio problem kada sam presao sa klasicnog OO programiranja na PL/SQL, prilicno je drugacija logika, ali kad se naviknes onda se pitas koji ce mi OO jezici za baze uopste, osim frontenda i nekih specificnih obrada.

U PL/SQL-u napises brzinski test code, dok se u Javi otelis.

Za neke obrade, procesiranja, daleko mocniji je bash/perl u kombinaciji sa PL/SQL-om.

Da ne spominjemo performanse, i kakve nebuloze Hibernate ume da napravi.

Za full text search je ES odavno pobedio ove integrisane u bazama.

Kako sinhronizovati podatke u ES i u glavnoj bazi u realtimu u OLTP ?

Ono kliknes commit i cekas da ES zavrsi upis kod sebe...

Inace distrubuirane transakcije su najveca mana mikroservisa i ono gde u nekim slucajevima gube od starog dobrog monolita.

Nismo nasli zadovoljavajuce resenje za to.

Ako imas nezavisne delove aplikacije koje ne moraju biti commit sinhrionizaovane, onda da, najbolje koristiti citavu menazeriju raznih baza, tehnika itd.

Ovaj pdf sto si okacio, to je neko istrazivanje, sve je to lepo, ali kada cemo to da vidimo u nekoj produkciji gde se obrce neka velika lova, i koliko ce da bude pouzdano, brzo i dovoljno jednostavno za implementaciju.

Sto se tice migracije Oracle -> postgresql, verujem da je moguca, ali pitanje je koliko vremena i resursa je potrebno za to.

Takodje pitanje performansi, cak i Oracle ovakav kakav je, utegnut maksimalno, gde mu je sve na lokalnom storidzu, ume da zaebe execution plan, ali ima fenomenalne dijagnosticke toolove, i razne tehnologije za optimizaciju slozenih upita. Ne znam da li to ima kod postgresql, ono malo sto sam radio izgleda mi kao prilicno jednostavnan RDBMS u odnosu na Oracle.

Edited November 20, 2025Nov 20 by brusli

10 hours ago, radisa said:

Upit na 10ak milijardi slogova u 20ak tabela sa gomilom nekih ukrštanja, filterom koji je nenormalan izvšava za manje od sekunde...

Zavisi, odnosno meni iz ugla korisnika se ne cini tako.

Ja koristim nekoliko reports koji se oslanjaju na MARC, MARA, SKAT, BSIS, ANLA i mozda jos par, i cesto se desi time out error. I onda run in background, pa cekaj dva-tri sata. Inace, report output je par hiljada redova sa 20-ak kolona, a mislim da nemamo vise od po 10-15 miliona records u svakoj od tabela.

Inace, cuo sam da SAP planira da eliminise BW, a i vrse veliki pritisak da se ukine i on-premise opcija za HANA.

19 minutes ago, Peter Fan said:

Zavisi, odnosno meni iz ugla korisnika se ne cini tako.

Ja koristim nekoliko reports koji se oslanjaju na MARC, MARA, SKAT, BSIS, ANLA i mozda jos par, i cesto se desi time out error. I onda run in background, pa cekaj dva-tri sata. Inace, report output je par hiljada redova sa 20-ak kolona, a mislim da nemamo vise od po 10-15 miliona records u svakoj od tabela.

Inace, cuo sam da SAP planira da eliminise BW, a i vrse veliki pritisak da se ukine i on-premise opcija za HANA.

On premis Hana je završila, više ne daju nikom da kupi on premis licencu (barem u Evropi), poslednju koju sma video je iz 2024... Još malo pa neće dati ni private cloud, kako su krenli, nego sve van standarda, jebite se i simulirajte kroz DSP...

BW4HANA, može još da se kupi licenca, ali mislim da su cene takve da se ne isplati i mora na DSP, na cloud...

Ovo gore sam pričao o ON-premis BW4HANA, sa 3TB rama, gde je oko 1.5TB free za kalkulacije... Na ERP-u, nism imao probelma, do sad sa samaim performansama, osim kod jako malih sistema, sa 192 ili 256 GB rama, ako radim samo an bazi... Ovo što kažeš mi čudnio, i liči mi da je upit rađen kroz ABAP, a ne direktno nad bazom, ako je već ERP... A to može da bude problem...Na erp-u se reporti bez obzira na HANA preformanse još vrte kao stari ABAP kod, ako su u GUI-u... i to je bullshit, ali menjaju polako...