Kada koristiti procedure u MySql-u

[ glamoc @ 05.01.2011. 21:43 ] @

Skoro sam prvi put koristio proceduru u MySql-u i posle mi se ucinilo da bih uvjek mogao napraviti proceduru i u njoj upit, i da bi to bilo cak i efikasnije od standardnog nacina.
Onda sam trazio po forumu i procitao da se procedure izvrsavaju na nekom drugom engin-u i da je on sporiji od standardnih.
Interesuje me savjet nekog iskusnijeg kolege kada treba upotrebljavati procedure i koliko se one brzo izvrsavaju

[ bogdan.kecman @ 05.01.2011. 21:52 ] @

mysql stored procedura ne moze da vrati rezultat u tabelarnom formatu ... dakle kakva je poenta da svoje upite ubacis u stored proceduru kada ona ne moze da ti vrati rezultat?

[ glamoc @ 05.01.2011. 22:14 ] @

Ok, ali mislim na slucajeve kad ih mozes koristiti tj. kad se ne vraca tabela vec neki rezultat.
Jel postoje neke preporuke kad koristiti procedure a kad slati samo upit pa rezultat obradjivati naknadno.
Pretpostavljam da odgovor zavisi i od toga koliko je jak sam server na kome se nalazi baza.

[ bogdan.kecman @ 05.01.2011. 22:26 ] @

stored procedura se koristi kada imas neku "proceduru" koju treba da uradis ... na primer "procedura za knjizenje" koja ce da iz tabele1 da povuce sve neuknjizene stavke, spoji ih sa tabelama 2 i 3 prebaci u tabelu4 i markira u tabeli1 kao proknjizene ... to lepo sve stavis u proceduru i to se izvrsi brze mnogo nego da to radis na klijentu... ali da ti napravis proceduru koja ce da ti insertuje 3 broja u tabelu tako sto ces input parametre ubacis u insert - to je cisto gubljenje vremena i energije i resursa...

cak i u takvim slucajevima, ume da bude korisnije da biznis logika (nacin knjizenja iz primera malopre) bude na klijentu a ne u bazi no stored procedura ce u tom slucaju uvek biti brza .

rule of thumb je da od 100 puta kada pomislis da bi stored procedura mogla da ti odradi posao - 90 puta nisi u pravu

[ dusty @ 06.01.2011. 00:11 ] @

Citat:

bogdan.kecman: mysql stored procedura ne moze da vrati rezultat u tabelarnom formatu ...

Nisam previse iskusan sa MySQL-om, pa me interesuje - kako to mislis? Sijaset stored procedura mi vracaju kao rezultat tabele, sto pri testiranju iz konzole, sto iz aplikacija koje koriste MySQLConncetor.

Inace, koristim za sve stored procedure (pa i najprostiji insert/update sa direktnim prosledjivanjem parametara) jer se desava da se logika treba izmeniti, a lakse mi je da izmenim storku na serveru, nego da reinstaliram aplikaciju na gomili desktop klijenata. Ok, mozda je za Web aplikacije drugacije i opterecuje server, ali zar se ne kesira execution plan? Video sam po vremenima izvrsavanja da za novu/izmenjenu storku (koja radi select) prvo izvrsavanje traje duze od svih narednih.

[ bogdan.kecman @ 06.01.2011. 06:28 ] @

kao sto rekoh - stored procedura ne moze da vrati rezultat u tabelarnom obliku .. to mislim bukvalno tako kako sam napisao ... dakle - ne moze, stored procedura ima in i out parametre i to je to .. ne postoji "tabela" kao parametar.

Ono sto moze da se koristi da bi sp vratila tabelu je da u sp kreiras temp tabelu (create temporary table t1 ...) i onda nju napunis sa rezultatom a onda posle poziva procedure dropnes istu .. (ili na pocetku procedure stavis sam da je prvo dropne ako postoji) ..

to sto ti verovatno radis je ..

Code:

create ...
...
begin
...
select a,b,c from t1;
...

i tebi mysql cli dampuje sadrzaj onog selekta na ekran odnosno sa raznim klijentima mozes "na razne fore" da "uvatis" taj izlaz iz stored procedure i da ga vratis aplikaciji ....

to NIJE REZULTAT te procedure, to je "debug output" te procedure koji ti "na foru" hvatas i koristis u aplikaciji ... sto je najbolje, taj isti debug output mozda sutra nece raditi .. dakle mi mozemo sad da odlucimo da u sledecoj MINOR verziji ukinemo da bilo koji konektor moze da pokupi ove vrednosti iz debug izlaza sp-a ... i tebi ce da prestane da radi aplikacija!!! (necemo posto ima gomila ljudi koji su vezali svoje aplikacije za mysql na tako pogresan nacin ali to je sad druga prica)...

sto se tice "kesiranja exec plan-a" ... ako ti radis nesto tipa

Code:

insert into t1 (a,b,c) values (1,2,3);
insert into t1 (a,b,c) values (4,5,6);
insert into t1 (a,b,c) values (7,8,9);
insert into t1 (a,b,c) values (10,11,12);
...

svaki upit ce trajati isto vreme

ako uradis

Code:

prepare statement "insert into t1 (a,b,c) values (?,?,?)"
set ... ; exec ps;
set ... ; exec ps;
set ... ; exec ps;
set ... ; exec ps;
...

u zavisnosti od konektora ili ce prepare da radi neko vreme i onda ce svaki exec prepared statementa da radi dosta brze nego svaki onaj insert od malopre ( i svi ce trajati isto) ili ce prvi insert biti sporiji a onda ce sve ostali biti brzi (i trajati isto)

a ako pak uradis

Code:

insert into t1 (a,b,c) values (1,2,3), (4,5,6), (7,8,9), (10,11,12)...;

ovaj insert ce trajati krace nego zbir i u prvoj i u drugoj varijanti

no to nema apsolutno nikakve veze sa sp-om, ako to radis unutar sp sve se identicno ponasa, dakle ako u sp radis prepare pa exec on kesira exec plan zbog prepared - ne zbog sp ... prepare mozes da odradis i iz svakog normalnog konektora ...

takodje, ako radis samo jedan insert (ili select ili ...) prepare ce biti sporiji nego da ga ne koristis

nadam se da sam bio jasan ..

btw za "rezultat" sp-a ... sta je rezultat ako imas:

Code:

..
begin
...
select 1,2,3;
...
select "A", "b", "c", "d", "e", "f";
...
select "error";
...
select 123,7;
...