Matt Sergeant writes:
> 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).
If you're considering a system which has stored procedures, you are
likely to have persistent servers. Once you update the database's
stored procedures, you have a consistency problem with code which
resides outside the database. Therefore, you have to bring down the
system or make each (stored procedure) release backward compatible.
Schema changes happen far less often than code changes.
> 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.
I think we have a disconnect here. Simple systems scale better than
complex ones. as you know, I argue strongly against storing state in
the middle tier, which adds complexity. The same argument applies to
stored procedures. Databases are good at storing data, not executing
code. The more the database has to do, the less reliable it will be
and the more of a bottleneck it becomes.
There was a book by Niklaus Wirth entitled:
algorithms + data structures = programs
The corollary in this world to me is:
business logic + schemata = OLTP systems
The clearer the separation, the easier it will be to build the system.
> > 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.
Referential integrity is extremely important. This doesn't mean that
all the data can be validated with referential integrity. A simple
example is a double entry bookkeeping system. You have to write an
auditor to validate the referential integrity of the books. You might
be able to write the auditor in stored procedures, but then he would
be better off implementing the entire system in stored procedures.
There's a commonality of code in the auditor and the rest of the
system. What you'll find is that the code and stored procedures is
duplicated in the user interface. You then have a maintenance
problems on hand, because you have to maintain two libraries which
implement the same functions.
Rob
