Prikazi cijelu temu
18.09.2013 16:15
18.09.2013 16:15
Predmet:Re: stored procedure Kako?
Views = prakticno isto sto i saved queries u Access. Razlika: uglavnom nije potrebno pisati view koji poziva drugi view, jer se SQL u MS SQL razlikuje od onog sto ima Access - mnogo je mocniji.
Stored Procedures = programi pisani u SQL jeziku koji podrzava tvoj sistem. Prihvataju parametre i mogu da rade osim vracanja podataka i izmenu (INSERT, UPDATE) pa cak i zimene struture baze i privilegija (CREATE TABLE, ALTER TABLE, GRANT)
Ako je Access front ENd, a MS SQL je back end, onda veliki broj stvari koje si radio u Access event procedurama se seli u SQL stored procedure. Na primer, ako hocesda kad se unese podatak u jednu tabelu, da se isti taj unese i u neku drugu tabelu, to sve mozes da uradis u stored proceduri, koju pozoves iz Accesa. Ako treba neko komplikovano pretrazivanje, Access query bice suvise spor - opet koristis stored proceduru koja to mnogo brze radi. Stored procedure pomazu u programiranju front enda. Umesto da kontrolu podataka vrsis na front endu, to radi stored procedura i svi programi koji menjaju podatke, ako pozivaju tvoju proceduru, radice na potpuno isti nacin i pisaces manje koda u Accesus - svi ce programi da pozivaju istu proceduru. Problem je ako ne kazes programerima da kosrite proceduru, ili zaborave da to urade.
Imas jednu specijalnu kalsu stored procedures, koja se zove TRIGGERS. Trigeri su stored procedures koje se zakace na tabele (kao event procedure na Access formama) i oni se izvrsavaju automatski kad se desi nad tabelmo neki od dogadjaja INSERT, UPDATE, DELETE. Pri tome trigger ne zna niti ga inetersuje kako se desio dogadjaj - direktnom naredbom, kroz Access formu ili kroz neku stored proceduru - trigger jedino zna da neko pokusava da promeni/obrise/doda podatke i triger ce svoj posao da odradi automatski. Trigeri se koriste za ugradjivanje poslovnih pravila i ogranicenja koje nije moguce postici na drugi nacin. Na primer, u tabeli [Izlaz] ne zelis da prihvatis unos ili izmenu ukoliko bi to dovelo do negativnog stanja. Ovo zahteva da pri svakom pokusaju promene podataka u tabeli Izlaz proveris kakvo bi bilo stanje posle te izmene i ukoliko je stanje negativno, triger jednstavno odbije promenu. Ovo je nesto sto bi pisao na BeforeUpdate za formu. Ako to pravilo stavis u trigger, onda ne moras o tome da mislis kad programiras, ni ti ni neki drugi programer koji bi mozda zaboravio da to uradi na forminom Before Update dogadjaju. Triger moze d apoziva stored procedures - i sad dobijas puniju sliku o tome sta se desava.
Pored stored procedures i triggers, imas u verzijama MS SQL 2005 pa naice i USER DEFINED FUNCTIONS. Funkcije mogu biti skalarne - posaljes parameter i funkcija vrati jednu vrednost, zatim mogu bit u stvari parametrizvani views - posaljes parametar i izvrsis se view s a WHERE @Parametar + <expression>. Imas i trecu vrstu funkcija koje sus lozenije od view-a, i isto tako vracaju tabele. Ovo ****lje nego stored procedures, jer tabele koje vracaju funkcije mozes da koristsi u SELECT izrazima unutar MS SQL, ali i iz Accesa, kroz pass-thru query.
Jedino sta treba da izbegavas jesy kursori (CURSORS) a to je nazalost suprotno onome sto pise u PDF koji je Zonic prilozio za TeraBite bazu.. Programerima je nazalost mnogo lakse da razumeju kako kursor radi (ili im se bar cini da razumeju, sto nije uvek sucaj), pa proizvedu veoma sub-optimalna resenja. Rad sa SQL procedurama i trigerima je vise SQL projektvanje i relaciona teorija, nego sto je programiranje. Ako mislsi samo da prneses programersko znanje sa Access nivoa na SQL, nije dobro. ZNanje o SQL i relacionim bazama koje sis tekao kroz rad sa Accesom nije dovoljno d abi se SQL koristio punom snagom, a ponekd je cak i stetno, jer te dosadasnje iskustvo navodi d au novom okruzenju radis stare stvari (ka na primer CURSORs). Znaci, nadji sto vise knjiga o SQL, u stvari o relacionoj teoriji jer ces morati da promenis nacin razmisljanja da bi nesto uopste napravio sa SQL.
Srecan rad :-)
Views = prakticno isto sto i saved queries u Access. Razlika: uglavnom nije potrebno pisati view koji poziva drugi view, jer se SQL u MS SQL razlikuje od onog sto ima Access - mnogo je mocniji.
Stored Procedures = programi pisani u SQL jeziku koji podrzava tvoj sistem. Prihvataju parametre i mogu da rade osim vracanja podataka i izmenu (INSERT, UPDATE) pa cak i zimene struture baze i privilegija (CREATE TABLE, ALTER TABLE, GRANT)
Ako je Access front ENd, a MS SQL je back end, onda veliki broj stvari koje si radio u Access event procedurama se seli u SQL stored procedure. Na primer, ako hocesda kad se unese podatak u jednu tabelu, da se isti taj unese i u neku drugu tabelu, to sve mozes da uradis u stored proceduri, koju pozoves iz Accesa. Ako treba neko komplikovano pretrazivanje, Access query bice suvise spor - opet koristis stored proceduru koja to mnogo brze radi. Stored procedure pomazu u programiranju front enda. Umesto da kontrolu podataka vrsis na front endu, to radi stored procedura i svi programi koji menjaju podatke, ako pozivaju tvoju proceduru, radice na potpuno isti nacin i pisaces manje koda u Accesus - svi ce programi da pozivaju istu proceduru. Problem je ako ne kazes programerima da kosrite proceduru, ili zaborave da to urade.
Imas jednu specijalnu kalsu stored procedures, koja se zove TRIGGERS. Trigeri su stored procedures koje se zakace na tabele (kao event procedure na Access formama) i oni se izvrsavaju automatski kad se desi nad tabelmo neki od dogadjaja INSERT, UPDATE, DELETE. Pri tome trigger ne zna niti ga inetersuje kako se desio dogadjaj - direktnom naredbom, kroz Access formu ili kroz neku stored proceduru - trigger jedino zna da neko pokusava da promeni/obrise/doda podatke i triger ce svoj posao da odradi automatski. Trigeri se koriste za ugradjivanje poslovnih pravila i ogranicenja koje nije moguce postici na drugi nacin. Na primer, u tabeli [Izlaz] ne zelis da prihvatis unos ili izmenu ukoliko bi to dovelo do negativnog stanja. Ovo zahteva da pri svakom pokusaju promene podataka u tabeli Izlaz proveris kakvo bi bilo stanje posle te izmene i ukoliko je stanje negativno, triger jednstavno odbije promenu. Ovo je nesto sto bi pisao na BeforeUpdate za formu. Ako to pravilo stavis u trigger, onda ne moras o tome da mislis kad programiras, ni ti ni neki drugi programer koji bi mozda zaboravio da to uradi na forminom Before Update dogadjaju. Triger moze d apoziva stored procedures - i sad dobijas puniju sliku o tome sta se desava.
Pored stored procedures i triggers, imas u verzijama MS SQL 2005 pa naice i USER DEFINED FUNCTIONS. Funkcije mogu biti skalarne - posaljes parameter i funkcija vrati jednu vrednost, zatim mogu bit u stvari parametrizvani views - posaljes parametar i izvrsis se view s a WHERE @Parametar + <expression>. Imas i trecu vrstu funkcija koje sus lozenije od view-a, i isto tako vracaju tabele. Ovo ****lje nego stored procedures, jer tabele koje vracaju funkcije mozes da koristsi u SELECT izrazima unutar MS SQL, ali i iz Accesa, kroz pass-thru query.
Jedino sta treba da izbegavas jesy kursori (CURSORS) a to je nazalost suprotno onome sto pise u PDF koji je Zonic prilozio za TeraBite bazu.. Programerima je nazalost mnogo lakse da razumeju kako kursor radi (ili im se bar cini da razumeju, sto nije uvek sucaj), pa proizvedu veoma sub-optimalna resenja. Rad sa SQL procedurama i trigerima je vise SQL projektvanje i relaciona teorija, nego sto je programiranje. Ako mislsi samo da prneses programersko znanje sa Access nivoa na SQL, nije dobro. ZNanje o SQL i relacionim bazama koje sis tekao kroz rad sa Accesom nije dovoljno d abi se SQL koristio punom snagom, a ponekd je cak i stetno, jer te dosadasnje iskustvo navodi d au novom okruzenju radis stare stvari (ka na primer CURSORs). Znaci, nadji sto vise knjiga o SQL, u stvari o relacionoj teoriji jer ces morati da promenis nacin razmisljanja da bi nesto uopste napravio sa SQL.
Srecan rad :-)