good chemistry is complicated, and a little bit messy -LW |
|
PerlMonks |
Re^3: Recoding a multi-sql-statement storedProc transaction in a scriptby mpeppler (Vicar) |
on Dec 15, 2004 at 16:00 UTC ( [id://415087]=note: print w/replies, xml ) | Need Help?? |
I'm with Thilosophy on this one. Sure, you might need to have DBA (or DBO == database owner) privileges to manage stored procedures, but that's actually a good thing - there should be some control on what SQL is run against a server, but source control is simply done the same way as with any other language - store source files in CVS (or perforce, or...), and load the source files to production systems in a controled manner (just as you'd move perl code into production in a controled manner). In terms of performance, my tests on Sybase show that stored procedures called as RPCs give the best performance because you don't have no SQL parsing overhead, and you usually don't have the query plan generation overhead either. I agree that doing procedural processing in SQL is bad, but if you can perform your requests as set operations then you're ahead. In addition, for Sybase at least it is important to keep transactions short, and wrapping them in a stored procedure is one way of achieving that. Michael
In Section
Seekers of Perl Wisdom
|
|