What happens when a database without stored procedures has to be migrated or
retired? You now have the application logic repeated in every app that uses
the database instead of stored just once in the database and you have to go
through ALL the apps to find out what'll have to change to accommodate the
new database.
"damorgan" <dan.morgan_at_ci.seattle.wa.us> wrote in message
news:3C7E6875.7D8DD6A1_at_ci.seattle.wa.us...
> Work on your resume. You are working with people who are getting their
technology
> advise from reading the newspaper.
>
> What a marvelous way to make a mess.
>
> Daniel Morgan
>
>
>
> Jimmy Bond wrote:
>
> > A group at my company is trying to ban the use of Stored Procedures.
Why?
> > Well, these are the reasons that they cite for banning SPs:
> >
> > - In the past, some projects in which a database needed to either be
retired or
> > migrated had problems doing this due to hundreds of unmanaged and
undocumented
> > stored procedures that had built up over time (NOTE: This occurred with
some
> > Sybase databases that were being migrated to Oracle)
> >
> > - To keep application logic out of the data tier
> >
> > - Because the company has no release management policies, guidelines or
> > automation for stored procedures
> >
> > - A company plan to build a Business Rules Engine sometime in the future
> >
> > - To help future portability of the database to another platform
(presumably
> > DB2)
> >
> > Yeah, I know this group's reasoning probably sounds like something out
of a
> > Dilbert cartoon, but I need more reasons than simply calling the group
> > techically incompetent to defend SPs and try to keep them from
establishing this
> > as a company policy.
> >
> > Can anyone give some great reasons why SPs should be allowed, and even
> > encouraged, in a development environment? (BTW, our projects' front-end
apps
> > are usually Java or C++ based, sometime with a Mid-Tier Application
layer)
> >
> > (Thanks in Advance)
>
Received on Thu Feb 28 2002 - 17:12:36 CST
