Re: stored procs? why?

On Thu, 28 Feb 2002, Rob Nagler wrote:

> Matt Sergeant writes:
> > Compared to hacking perl code - absolutely. Plus SP's are almost always
> > harder to debug.
>
> don't forget about versioning and backing out changes.  It's one thing
> to deploy an RPM and revert it to the previous version.  It's another
> to back out a stored procedure change.

I can't agree with this. We sometimes make RPM's to install SPs, so it
works almost exactly the same as with scripts (note though that RPM has a
fundamental problem here - it's not transaction safe! If you update 20
modules but one gets called mid-update, all hell can break loose, unless
you're using a persistent perl engine like mod_perl and issue a restart
after the install).

> Scalability is sacrificed when the database becomes a compute engine.

I can't agree with this either. The term "scalability", often used to
refer to middle tier stuff, is vastly overrated in favour of fundamentally
faster systems in the first place.

> when you have multiple languages accessing the same database, you've
> got a mess.  This is one of the strongest arguments for middleware
> that I can think of.
>
> Another nice thing about keeping the database simple is that you can
> substitute mock objects which inject faults, automatically generate
> valid data, and interactively test the business logic more easily.

This seems to me to assume lack of relational integrity. I would never
design a system that even began thinking about using SP's if it didn't
have full relational integrity within the database. You can't buy the kind
of piece of mind DRI brings you.

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