> In environments with lots of applications accessing the
> same database they also add more value. (Though this can
> backfire in case of testing changes to stored procs )
This is IMHO not true. The simple reason for this is that once you have
a proc which is used by multiple apps, you can't
change it if it needs a new parameter/different type/updated resultset, because
it will break a lot of apps, and perhaps these
aren't written in-house. So what do you do? You add a new one. After a couple
of years, how do you think your db will look like?
> In Environments with good DBA's responsible for
> managing the stored procs they are easier to maintain.
The procs maybe, but that's just half of the story. How about the code
calling the procs? Ever written an n-tier application
with procs? So when a proc had to change, you not only had to change the proc
but also the calling code? The proc is then managed by
the DBA, but the calling code isn't.
What if the DBA is not available that day? Or has other ideas about the
interface / signature of the proc? Not fun. It will
slow down development for no real reason.
> In environments where the SQL is managed by the
> developers they are a hindrance to the operators who have to
> add the scrips to production each time they change.
True.
FB
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
