Re: stored procs? why?

On Thu, 28 Feb 2002, brian moseley wrote:

> On Fri, 1 Mar 2002, Matt Sergeant wrote:
>
> > Given that though, it becomes very easy to see that if
> > you do have a large transaction (including multiple
> > table updates for example), it's often safer to
> > encapsulate that into a single stored procedure than it
> > is to write some large chunk of Perl that turns off
> > AutoCommit, does the work, and then commits. Plus it
> > ensures people can use other languages to execute the
> > same transaction. If you want to use SOAP/HTTP to
> > emulate a stored procedure to achieve the same effect
> > you're welcome to, but beware of the performance.
>
> beware the tremendously inflated development schedules that
> can result from this approach. at critical path, we used a
> lot of pl/sql stored procs for validation, integrity checks
> and transactions. almost every development schedule for
> adding or modifying features to the service was blown out by
> the stored proc development effort.

Compared to hacking perl code - absolutely. Plus SP's are almost always
harder to debug. Nothing is without tradeoffs - this is why you still need
people who know their stuff working for you ;-)

-- 
<!-- Matt -->
<:->Get a smart net</:->