zavisi

imas prednost
- da ce procedura izvrsavati upite bez overhead-a koji aplikacija ima (hendlovanje konekcije, prica izmedju klijenta i servera...)
- da kada bekapujes bazu bekapujes i te stored procedure

imas mane
- da ti je biznis logika u bazi umesto u aplikaciji
- da biznis logiku moras da pises u vrlo rudimentarnom / limitiranom jeziku sa vrlo rudimentarnim (5.5) odnosno nikakvim (<5.5) error hendlingom
- security za stored procedure na mysql-u je jos gori nego za obican pristup tabelama
- debugging skoro da ne postoji

Ja licno mislim da su mane previse ozbiljne da bi takav pristup bio valjan... takodje moje licno misljenje je - multilayer, jedan zaseban layer sa biznis logikom i taj layer ne treba da sedi na bazi vec u app layeru... e sad, na tebi je da odlucis... ne postoji univerzalan odgovor .. zavisno od ostalih faktora jedan ili drugi ce imati dodatne mane / prednosti

Pretpostavljam da seovo odonosi na MySQL. Radio sam na neki projektima sa drugim bazama i nismo imali problema sa korišćenjem stored procedura u aplikativne svrhe. Čak je prilično dobro radilo.

Ne bih baš išao dotle da storded procedure pripisujem nivou podataka. Ipak je to već svojevrstan aplikativni nivo, samo je smešten u samu bazu.

pa ne bas samo za mysql ...

u svakom rdbms-u koji ista valja se stored procedura izvrsava bez overheda i bekapuje se zajedno sa podacima :) ...

sto se mana tice, postavljanje biznis logike u bazu je PO MENI mana, znam ljude koji misle da je to prednost, ja se izrazito ne slazem, svejedno da li je to oracle ili mysql, sto se tice rudimentarnog jezika, to jeste vezano za mysql posto oracle daje poprilicne mogucnosti, pgsql takodje .. za security - nemam pojma kakav je security na ostalim rdbms-ima za stored procedure, na mysql-u je ceo taj auth deo prilicno dzagaljigav za moj ukus... planiraju se neke lepe stvari ali to dok dodje na red meni vise nece trebati, drizzle je tu napravio lepu pricu sa plaginom za auth tako da oni vec imaju jako dobar sistem, doduse u dev stablu, u GA stablu je to prilicno pateticno kao i sam mysql ... za debugging, za mysql znam da ne postoji, ima nekih pateticnih alata ali su stvarno pateticni, radi se sad na debugeru koji ce biti implementiran u WB a da bi radio u WB ce se iskopirati ceo kod iz servera pa ce WB interno da debagira ... patetika, na zalost ... za ostale ne mogu da se pohvalim da sam imao mnogo vise srece, sa pgsql-om sam pokusavao razne metode da izdebagiram neke stored procedure - bezuspesno, na oracle-u takodje, iscimao sam kolege kojima je to posao i na kraju smo izdebagirali tako sto je lik terao ceo orakle kroz debager tako da .. ni on nije bas srecan po tom pitanju .. (mnooooogo srecniji od mysql-a ali .. i dalje ne po mom ukusu) ... mssql nisam nikad u zivotu probao da napisem stored proceduru, jesam mnoge prepisivao prilikom migracije na mysql tako da nemam ideju da li podrzava debagiranje ili ne mada poznajuci mysql ima sigurno nekakav debugger i verovatno je vrlo dobro nasminkan sa milion opcija i spor do zla boga, nadam se da gresim :D no stvarno nisam nikad ni probao ...

no uvek stoji to da ne postoji univerzalni odgovor tu ... kada sam se ja pocinjao baviti racunarskim sistemima i velikim bazama podataka bili su tamo neki VMS, UNIX (ultrix, irix, xenix) sistemi na koje si se kacio nekim terminalima okacenim nekom seriskom vezom .... to je bio "idealan nacin", sve je bilo centralizovano ... onda su dosli personalni kompovi, presle su aplikacije na desktop a veci sistemi su dobili multilayer arhitekturu gde je nesto bilo centralizovano (baza i application layer) a nesto je bilo na klijentu (gui) ... onda su se pojavili kliperasi koji nisu mogli da skapiraju multilayer programsku semu pa su rokali po deljenom fajlu podatke ... onda je dosao web tamo pocetkom devedesetih i krenulo se polako sa konceptom "player-a" na klijentu (html, javascript, flash, xml...) i serverske aplikacije da bi se lagano doslo na web 2.0 gde je player presao da bude full time gui na klijentu ... da bi sada i za one vrlo "desktop" aplikacije razdvajali gui na klijentu a aplikaciju na serveru (google docs na primer) .. tu sada stvar dolazi dosta do privatnih preferenci - ja licno mislim da je debilno da ja na desktopu sa grafickom kartom od 1000EUR i 24G rama i 8 i7 jezgara teram "internet exploder" da bi napisao neki tekst ili editovao sliku ... prosto odbijam da se vratim nazad u 198x godinu ... opet, eno ga 10% sveta ne moze da prestane da vice "cloud cloud" i placa sumanute cifre amazonu za stvari koje bi mnogo jeftinije platili da uzmu regularan dedicated server ... opet - moje privatno misljenje posto sam ja prosao taj centralizovan sistem vec jednom i sada se vratio na njega, znam vrlo dobro koje su mu prednosti ali znam isto tako i njegove mane ... no ... to je za neki drugi forum :D

Nemam puno iskustva na praktičnim projektiva vezanim za MySQL ali mogu da kažem da na ovom projektu na kojem sad radim koristimo taj pristup da aplikaciona logika bude u stornim procedurama na serveru baze podataka i mislim da je to loš pristup zato što kod MySQL-a se ne mogu hvatati greške kao recimo kod Orakla. To je velika mana.

receno ti je bilo pre nego si krenuo da radis taj projekat da je los pristup, ali nisi hteo da slusas <-:E elem, kad smo kod vatanja poruka, rekoh da sa 5.5 ima i signal i resignal ... tako da ako se upgradeujes ..

Da, da, baš ti si mi rekao da to nije dobro, ali ipak nisam samo ja odlučivao.

c'est la vie

probaj bar da ih ubedis da predju na 5.5 .. olaksacete sebi zivot znacajno

To ne bi bio toliki problem, ali ja još uvek nisam svestan koliko bi moglo to da mi pomogne, pogledaću malo taj signal i resignal.

Jel možeš Bogdane da mi daš jedan praktičan primer kako bi mogao preko toga da implementiram upravljanje greškama?

@mar.kisha:

Generalno nije dobro stavljati "biznis" logiku u same SP, medjutim ako imas nekakvu logiku "podataka" onda mislim da je bolje to staviti u SP.
Na primer, ako imas operaciju nad entitetom koji je kompleksan, gde se podaci nalaze u vise tabela,
bolje je koristiti SP jer onda kompleksnost zapisa entiteta ostaje samo u bazi i ne propagiraš je u više aplikacione slojeve.

Mislim da je loše "ponašanje" i "logiku" aplikacije programirati u DB-u.
Znači, ono što se tiče podataka i sirovih operacija nad njima u DB, ostalo kao deo aplikativne i biznis logike.
Po onome što si napisao, liči mi da je to posao za SP ali ne mogu da tvrdim.

odavno nisam procitao post da sam morao 2 puta da se vratim da budem siguran da ga nisam ja napisao :D ... sta reci, ja se slazem 10000% sa ovim sto je dusans napisao ...

sad, ja licno preferiram trigere umesto sp-a iako je nekada lakse odraditi nesto preko sp-a ... ali sa sp-om ne mozes da zabranis direkt menjanje podataka (uvek mozes da imas morona koji ce da krene da edituje tabele direkt)

jos jedna stvar koja ima smisla da ide u sp je "arhiviranje" ... recimo da pravis neki rrd log .. cuvas zadnjih 24h podatke na sat, zadnjih 7 dana na dan i zadnjih 2 meseca na nedelju ... ti realno hoces svakih 24h da odradis neko "prepakivanje/arhiviranje" gde ces sve iz "satne" tabele starije od 24h da prebacis u dnevnu, sve starije od 7 dana iz dnevne u nedeljnu, sve starije od 2 meseca iz nedeljne u smece ... to mozes da turis u neki skript koji zoves iz nekog cron-a i onda ti sysa resetuje server posle nekog upgrade-a i zaboravi da starta cron ili ... ili mozes da nacukas to kao sp i schedulujes event da pozove istu jednom dnevno ... e sad, ma koliko ja kazem da je ovo ok primer za sp, ja u 99% slucajeva to opet stavljam u externi shell/php script posto obicno dnevno radim jos kojekakve kalaku***je tako da taj "management" script na sat vremena ili na 24h ili kako je vec napravljen radi jos ko zna sta (npr pravi bekap, kopira ga na susedni server, inicira bekap na traku etc..) a sve to u zavisnosti od trenutnog stanja servera (ako sam radio bekap i arhiviranje pre cuku vremena a sada je load na serveru 20 mogu da sacekam sledeci sat pa onda da to radim da ne opterecujem bez veze vec preopterecen server) posto to ne moze (jos uvek) da se odradi iznutra iz mysql-a

Ljudi, hvala vam na iscrpnim odgovorima...

poslije svega pročitanog, skontao sam da će mi upisivanje preko SP bolje odrađivati posao.
Hvatanje grešaka mi i nije baš najpotrebnije, jer MISLIM da do njih neće doći.
Stvar je jednostavna...SP prima podatke, u zavisnosti od nekog parametra vrši računanje i upisuje u jednu ili više tabela.

E sada, i dalje ostaje pitanje (možda je glupo, ali je pitanje! :) ) - da li je bolje (za opterećenje servera) da se radi u jednoj sekundi 50 poziva iste procedure, ili 50 SELECT + 50 INSERT?

pa ako pozoves 50 puta proceduru koja ne radi nista u poredjenju sa 50 selectova .. bolje za performanse 50 puta ovo sto ne radi nista ...

ali ako pitas da li je bolje da pozoves 50 puta proceduru koja izvrsi 1 insert i 1 select ili 1 proceduru koja pozove 50 inserta i 50 selecta - bolje je ovo drugo