ugrás a tartalomhoz

Stored procedures are bad, m'kay?

Bártházi András · 2005. Okt. 28. (P), 22.11
Egy jó kis vita arról, hogy kellenek-e tárolt eljárások
 
1

Mi is az, amiről itt szó van?

Bártházi András · 2005. Okt. 28. (P), 22.15
A hozzászólásból nem feltétlenül derül ki, hogy miért is gondolja a szerző azt, hogy a tárolt eljárások használata felesleges. Röviden: ő amellett van, hogy a kis futtatandó programokat dinamikusan kellene összeállítani, s nem egyszer előre, majd azt tárolt eljárásként eltárolni. Tehát csak a tárolt eljárások tárolása ellen van. Szerintem. Mivel nincsenek nagy tapasztalataim ezen a téren, én nem foglalnék állást, hogy igaza van-é? :)

-boogie-
2

Összetettebb a kép

Hodicska Gergely · 2005. Okt. 30. (V), 13.27
Röviden: ő amellett van, hogy a kis futtatandó programokat dinamikusan kellene összeállítani, s nem egyszer előre, majd azt tárolt eljárásként eltárolni. Tehát csak a tárolt eljárások tárolása ellen van.

Nem egészen erről volt itt szó. A kiváltó blogbejegyzésben arról volt szó, hogy miért jó tárolt eljárásokat használni; alapvetően ezek az érvek merültek fel: teljesítmény, biztonság illetve architektúrális szempontok.

A beérkezett hozzászólásokban, illetve Frans blogbejegyzésében ezt többnyire elég jól cáfolták.

1.) Teljesítmény: Rob szerint a tárolt eljárások előfordításra kerülnek, és mindig gyorsabbak is, mint a dinamikus lekérdezések, melyekről ráadásul leírta, hogy azok végrehajtási tervei nem cache-elődnek. Ez nem így van, mint a hozzászólásokból is kiderült. Ami ebből a szempontból érdekes volt, hogy annyi előnye adott esetben lehet a tárolt eljárásnak, hogy ha nem is gyorsabb, mintha különálló SQL parancsokkal valósítanánk meg a funkcionalitását, csökkenhet a hálózati kommunikáció, és ezért lesz gyorsabb.

2.) Biztonság: itt az volt a fő ér, hogy nem kell közvetlen elérést adni a táblákhoz, de ezt egyéb módszerekkel is meg lehet oldani, mint azt több bejegyzésben is vázolták.

3.) Architektúrális kérdések: Rob szerint a tárolt eljárásokkal egy interfészt alakíthatunk ki, amely segítségével elfedhető az adatbázis szerekezet, bizonyos változtatások esetén elég a tárolt eljárásokat megváltoztatni, és az őt használó program ebből nem érzékel semmit. Ezt is elég rendesen tudták cáfolni, és ha bele gondolunk, azért kevés olyan változtatás lehet, ami a fent vázolt módon elkendőzhető.


Persze az igazság valahol most is félúton, bár jelen esetben talán inkább negyed úton van, mint mindig. Mindenre tárolt eljárást használni valószínüleg az esetek többségében felesleges. Dolgoztam én is olyan rendszerrel, ahol nagyon fontos volt a biztonság, ezért minden csak tárolt eljárásokon keresztül volt elérhető (annak érdekében, hogy az authentikáció, jogosultságok ellenőrzése teljes mértékben az adatbázison belül maradjon), de viszonylag macerás volt. Eléggé figyelni kellett a dokumentációra, különben az ember meg volt lőve, amikor 50-100 paramétert kellett átadni, ott is könnyű volt hibázni, szóval nem volt egy leány álom, de ott eléggé speciális igények is voltak.

Álatalában akkor lehet célszerű tárolt eljárás alkalmazása, ha több olyan műveletet fogunk össze, amelyek logikailag összetartoznak, és csak együtt van értelmük. Ezekt kivonhatjuk egy tárolt eljárásba, így csökkenhet a hálózati forgalom, és a kódunk is átláthatóbb lesz. Lehetnek egyéb esetek is, de a lényeg az, hogy az eszközt ne túlhasználjuk, hanem konkrét esetekben döntsük el, hogy van-e értelem, nyerünk-e vele.

Egy másik rendszer kapcsán is tallálkoztam azzal, hogy volt 1000-es nagyságrendű tárolt eljárás, elég nehézkes volt a használtat, bár ott főleg a dokumentáltság miatt.


Plusz én mindig szeretem egy külön objektumban tárolni az összes adatbázis kezelő kódot, így bármilyen változtatás van, akkor csak abban kell átvezetni, és nem kell keresgélni szanaszét a programban, és ez független attól, hogy tárolt eljárást használunk, vagy közvetlen SQL lekérdezéseket.


Felhő