Re: stored procs? why?

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.

Scalability is sacrificed when the database becomes a compute engine.

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.

> Nothing is without tradeoffs - this is why you still need
> people who know their stuff working for you ;-)

I think that's what this discussion is all about.  It's really hard to
make these trade-offs out of context.  The sad part is important
decisions like these are taken well before they need to be.

Rob