Re: stored procs? why?

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.