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</:->
