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