stored procedure, sve ili ništa?

Imam elementarna znanja sql-a i programiranja a hteo bih naučiti nesto više. Svrha? - za sada čista razonoda (kao i stara ljubav prema programiranju). Međutim, nisam baš navikao da "učim" tj čitam gomilu teksta pre nego što bilo šta započnem, već najlakše učim ako imam konkretan problem koji želim da rešim - i to ne mogu/ne želim da menjam. Zato se izvinjavam ako pitanja dole nisam "dobro formulisao" tj. ako preskačem gomilu stvari koje sam trebao da znam pre nego što postavim ovakva pitanja.

Za sada sam izabrao da napravim programče za magacinsku evidenciju gotovih proizvoda, a za to koristim dbms: mySQL i programski jezik: Java.

Zanima sledeće: koliko je izvodljivo da za SVE manipulacije sa podacima baze (recimo upis, brisanje i sl) imam uskladištene procedure koje bih pozivao iz programa?

Dakle, poenta je da izvan baze nemam ni pregled podataka a da on nije "potekao" iz baze. Da li je takvo rešenje moguće/prihvatljivo i da li razmišljati u tom pravcu?

to je *moguce* ali
1. nema svrhe
2. nije dobra praksa
3. cemu?

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Za pod 1:
Kojekuda (za M$ SQL Server) se zbog bezbednosti (prvenstveno eliminisanja opasnosti od sql code injection) preporucuje da klijent aplikacije operacije nad bazom obavljaju putem procedura. Postize se i dodatna bezbedost jer se klijentu daje samo pravo da izvrsava stored p. dok su mu prava da direktno radi sa tabelom ukinuta. Takodje, (opet praksa sa M$ SQL Servera) je da se dobija na performansama, jer se za stored procedure query execution plan kesira.

Sve ovo gore ima smisla kad je M$ SQL Server u pitanju, mozda ima smisla i kad je MySQL u pitanju, no Bogdan sigurno ima dobre razloge kad kaze da na MySQL to nije dobra praksa.

Mislim da su vam prepared statements bolje od klasicnih procedura za ovo sto hocete.... Moja 0.02EUR.

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

zato sto m$ alate realno 90% koriste retardi bez osnovnih znanja. to ne menja cinjenicu da je to LOS DIZAJN, pri tome nije m$ taj koji daje tu preporuku a oni koji daju je daju pokusavajuci da zastite rupe u win aplikacijama, pritom je to i dalje losa preporuka jer se opet ne stiti nista, jer i dalje maliciozan moze da izvuce user/pass za pristup bazi i da zaobidje celu tu cuvenu m$ zastitu .. (cim dobije pristup bazi "na bilo koji nacin" m$-ove zastite tu padaju u roku od 10-30 minuta bez obzira na "finely grained" user permission tree koje m$ nudi, kao i za sve ostale proizvode m$ nema ideju kako se radi security)

zna se cemu sluze stored procedure, to nije sigurnost, abitno da li je u pitanju oracle db ili mysql / pgsql ili m$ sql



ne kesira se query exec plan za stored procedure ni na m$ sql-u ni na mysql-u... stos je u tome sto ako pises stored procedure velika je sansa da ces koristiti preparaciju statementa a tu se kesira exec plan, ali kao sto mozes u stored proceduri da ne radis prepared tako mozes (i trebas) da koristis prepared van stored procedure tako da je tu opet m$ hint za tupave usere koji nemaju osnovna znanja o tome kako radi rdbms ..




isto nema smisla za m$ koliko ni za mysql, kao sto rekoh, mozemo da pricamo cemu sluze stored procedure i kada imaju smisla, security nije u toj prici

@nkrgovic, preparacija statementa treba da se koristi (nekad i mora) i ima svoje prednosti i to sa sp nema nikakve veze (ma koliko u m$ svetu zaobilaznim putevima pokusavaju da rese osnovna neznanja svojih korisnika) ... na zalost, mysql kaska dosta za konkurencijom po pitanju prepared statement-a (dosta konektora podrzava samo prepared statemente direkt na klijentu sto je dovoljno za security ali nema nikakvog kesiranja exec plana, do skoro je i tamo gde je radio server side prepared statement isti bio mega bagovit .. trenutno server side radi lepo na javi, php na zalost jos uvek samo client side..) ... tu je konkurencija znacajno naprednija i pgsql i m$sql rade normalno server side prep.s. kroz sve konektore (m$ cak ako se dobro secam, mozda gresim, nema uopste podrsku za client side prep.s. u oficijalnim konektorima)

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

@bogdan: Meni je za ono sto oni navode da im treba delovalo da je prep.stat. dobro resenje. Enkapsulacija, delimicno izbegavanje injection-a i sl. Kesiranje exec. plana mi nije bila namera, vec samo elegantniji kod i bolje organizovana struktura.... ono sto oni probaju da kopiraju sa MS SQL-a.

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

@nkrgovic, ma preps mora da se koristi "to je dobra praksa" u svakom slucaju .. da je @sbin odgovorio na pitanje "zasto" pa da mu pokazemo kako se to stvarno radi ovako mi iskreno nije vise do nagadjanja .. gledam ja kakve savete daju kolege za oracle db, veze to sa vezom nema, i onda kad navalis da dobijes razlog "zasto" se neki savet daje dodjes do toga da je to "najlaksi nacin da se idioti koji se tripuju da su dba i dbd smanji mogucnost pravljenja mega sra123" .. no odosmo od teme ..

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

da se ukljucim, pa da pitam bogdana koji je car ovog foruma, sa prvom tackom se slazem da prebacivanje svega u procedure ne treba biti samo sebi svrha, tj nema svrhe da se to radi tek onako. Stavka dva me interesuje "nije dobra praksa" i "los dizajn", da to obrazlozis u par recenica. Kada se vec napravi takva postavka sta je to toliko lose u praksi sa tom postavkom? Stavka 3 Cemu je u potpunosti ispravna, jer sta znaci preporuka M$. nista za onog ko zna posao.

Da ja dodam svoja dva centa što se tiče Oracle baze:

1. Šta god može da se uradi sa SQL-om - uraditi u SQL-u
2. Ono što se ne može uraditi u SQL-u uraditi u PLSQL-u. Ako ima dosta računanja, proceduru/paket kompajlirati u NATIVE modu - Oracle onda prebaci PLSQL kod u C, iskompajlira ga i napravi od njega deljenu biblioteku.
3. Ono što ne može u 1. i 2. napisati u host jeziku.

Situacija u kojoj se pišu u Oracle bazi procedure za pristup tabelama je samo onda kada se korisi Apache mod_plsql. Tada procedure ne treba da da samo skup redova kao izlaz nego ceo http response.

Ah, da dodam još jednu stvar za PLSQL procedure - Oracle kešira PLSQL procedure. Kao rezultat kompajliranja PLSQL procedure, kreira se DIANA (Descriptive Intermediate Attributed Notation for Ada) koja je struktura tipa stabla i proizvod je parsiranja PLSQL koda. Na osnovu ovoga, Oracle zna zavisnosti među procedurama i može da proveri da li se neka procedura promenila, pa mora ponovo da je iskompajlira, kao i m-code koji je, u stvari, ono što Oracle server izvršava. Dakle, ako je PLSQL procedura keširana, onda se uštedi vreme za parsiranje i kompajliranje...

_{[Ovu poruku je menjao djoka_l dana 17.06.2015. u 10:25 GMT+1]}

@orome, "Stavka dva me interesuje "nije dobra praksa" i "los dizajn", da to obrazlozis u par recenica" mu ide gde i prva, ako je ubacivanje svega u stored procedure svrha sama sebi onda je to losa praksa i los dizajn, zar ne :) ... stored procedure sluze za obradu date, ne za dohvatanje date, dakle ako treba da preracunas nesto nad velikim skupom podataka to radis u stored proceduri jer je glupo da ti sad prebacis svu tu datu na klijent da bi radio nad tom datom neku (najcesce glupu i jednostavnu) operaciju i onda vracao rezultate na bazu .... da bi sprecio taj put tamo vamo napravis obradu u sp, pozoves sp i to je to ... e sad tu imas 2 struje, jedna struja kaze, ako ti je vec deo biz logike (ta obrada) na bazi, onda bolje da ti sva biz logika bude na bazi pa app ne radi nista, tu onda mozes da prezivis sa developerima koji potpuno abstrahuju datu i nemaju pojma sta je to sql i od kojih zive prodavci jacih i jacih servera jer im prosecan upit traje par minuta i imas struju koja kaze da biz logika ne treba da bude na bazi vec treba da bude u aplikaciji, gde se na bazu prebacuje samo ono sto nema smisla da sedi u aplikaciji i gde se odrzavanje tih sp radi iz aplikacije a ne od strane dba... tu imas veliki benefit sto aplikacija moze da bude optimalna ali veliki problem sto moras da imas developere sa mozgom jer isti mogu da naprave veliko sra123 ako isti nemaju

@djoka, imas problem sa babama i zabama :D (mysql je ovde kamencic), oracle nije samo rdbms vec app server, kada se oracle koristi kao rdbms ta preporuka ne vazi (sve sto moze u (pl)sql, odradi u (pl)sql), dakle svi novi oracle konsultanti ce ti reci ako ne koristis oracle forms i ostali oracle middleware da prebacis aplikaciju na app server a bazu ostavis bazi .. problem tu je sto ima mnogo stare garde koji i dalje misle da je oracle forms najbolja stvar posle rezanog leba pa je sa njima nemoguce komunicirati .. sve u svemu, ako pises aplikaciju u forms-u, da to je tacno sve, ako pises aplikaciju u javi, c++ ili slicno onda ne, to nije tacno... sad, ja licno, preporuku da li oracledb koristiti kao app server, kao rdbms ili kao nesto izmedju, nikad, ali bas nikad, ne bi mogao da dam odokativno, bez da sednem i dobro pogledam projekat .. vecina ljudi koji se bave tim poslom imaju cvrst stav da "uvek" treba samo jedno, ja smatram da je to glupo i da je prednost orakla u odnosu na ostale sto nudi izbor i da taj izbor treba iskoristiti onda i onako kako je to za neki projekat najbolje ... sa druge strane porediti mogucnosti oracle app servera i mysql-a je, u blagu ruku receno, smesno ... volimo mi mali da lajemo i da se guramo svuda ali oracle i mysql su dva potpuno odvojena sveta sa mnogo malo preklapanja, mysql podrzava samo vrlo osnovnu sintaksu za sql stored procedure, po sql standardu, i to je to, mozda se u dogledno vreme prosiri do mogucnosti koje m$sql nudi sa t_sql ali to je plafon, dobaciti do toga sta sve pl_sql moze, koliko ja znam, ne postoji ni u najdugorocnijem planu koji imamo .. za pocetak bi debagiranje postojecih sp na neki "koristan" nacin bilo vise nego dovoljan korak napred :)

mnogo je, recimo, korisnije uporediti pgsql, on nije app server poput orakla a ima podrsku za plsql i jos mnogo drugih nacina za pisanje stored procedura (nemam pojma da li ih kompajlira interno ili ne) pa videti kakve su tu preporuke ... mysql je suvise sakat u prici sa sp i sf da bi bio ozbiljan igrac u bilo kom slucaju, pgsql radi sve sto vole mladi.. nije toliko brz i toliko rasiren ali mu mogucnosti nikako ne nedostaju .. ja znam mnogo veliki firmi sa nekim zverima koje rade kao arhitekte i nigde nisam video da se preporucuje guranje biznis logike u sp ... naravno tu je i dalje armija bivsih oracle forms 2 korisnika koji ne razumeju potrebu za "host jezikom" ali ipak smo u 21. veku..

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

U pravu si (donekle) kad je u pitanju PLSQL u Oracle bazi.

Kada sam rekao sve u PLSQL što ne može u SQL, pre svega sam mislio na primer koji si ti dao, kada treba da se obradi gomila redova, pa umesto da se redovi vuku na klijent, onda je bolje da ostanu lokalno na bazi i da se posao završi u PLSQL-u.
Takođe, sve komplikovane validacije koje ne mogu tako lako da se izvedu kao constraint nad tabelom staviti u trigere i procedure.

Što se tiče formsa, sve priče oko toga da ga treba izbegavati koje puštaju razni konsultanti su čist hype. Iz iskustva vidimo da je razvoj u Javi, na primer, 3-10 puta sporiji nego u Formsu. Na kraju se projekat svede na situaciju da Java tim uradi gomilu posla koje bi inače uradio forms wizard.

Što je još gore, sa sve upotrebom ultramodernih alata, na kraju imaš situaciju da je aplikacija koja se intenzivno razvija online za testiranje 15 minuta dnevno, dok sa formsom imaš gomilu funkcionalnosti koje su veoma lokalne, pa je veći deo aplikacije stalno raspoloživ za test, a da bi stvarno srušio aplikaciju, potrebno je da jako mnogo stvari promeniš.

pazi, ja necu da se stavljam ni na stranu formsa ni van formsa.. ja ih
licno ne podnosim i mislim da argument koji si dao ne stoji, al opet,
nemam neki problem sa, po meni, zastarelim tehnologijama, i ja sam vrlo
cesto u zivotu radio sa "zastarelim" tehnologijama i nisam se mnogo
obazirao na one oko sebe i na moderan hype ..

elem, ja nisam konsultant za oracle niti zelim da se bavim time ali sam
ispratio mnogo oracle projekata sto sa formsima sto sa javom sto sa c++
sto sa .not i ne slazem se ni malo sa tobom oko toga ... prvo to oko
testiranja je samo do organizacije, nista drugo, ako imas losu
organizaciju neces dobiti ni tih 15 minuta ... takodje ti pricas o
organizaciji posla iz proslog veka, gde imas "java tim" i "db tim", to
je po meni zastareo, uzasno los, model organizacije... to da 3 lika pisu
upite, store procedure i views a druga tri lika pisu "gui" i koriste
gotove komponente koje mapiraju one sp i views direkt kao data source na
njihove aplikacije je 20ti vek ... probaj da se zaposlis u nekoj
ozbiljoj dev kuci sa tim stavom, nema sanse, od tog "java programera" se
ocekuje da zna SQL + plsql ili tsql ili koji vec rdbms je u upotrebi u
toj kuci

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Mislim da ni kad je M$ SQL Server u pitanju, to vise nema smisla. Sada tj. vec dosta vremena koriste se Entity Framework ili nHibernate. Tako da skoro da i nema vise nekih potreba za procedurama.

Opet, EF, moze da poziva i koristi SP.