Your point about isolation from vendor-specific SQL makes a lot of sense, although I wonder how standardized the details of calling procedures is across databases in DBI. Typically, database portability only really matters to people who are shipping a product that must support multiple dbs. Other people are not willing to spend the time and money that portability requires.
I still don't buy the idea that stored procs can provide protection from schema changes of any significance. If there was a good reason to make the change, it must mean the available data is now different, which means the programs using it need to change. Little things like adding columns don't break SQL -- big things like merging or splitting tables and changing relationships do. Trying to hide changes like that behind stored procs and let programs continue as if nothing happened will surely result in slow and complicated joins and the like.
In reply to Re^5: No stored procedure bashing on my watch!
by perrin
in thread Recoding a multi-sql-statement storedProc transaction in a script
by punkish
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |