David's argument is for a single-app database, because he doesn't
believe that applications should integrate directly with each other's
databases. As such, all databases are single-app databases.
Ah ... but at that point, in many ways, he's wrong. The moment you have
data to migrate, there's a second program working on the database.
Unless -- as appears to be the case with Rails at this point -- your
migration is done using the exact same database access layer as your
primary application, you will get garbage data at some point.
[...]
This ultimately boils down to a difference in opinion on design.
Not really. It boils down to good and bad practices. I think that the
decoupling that David advocates is a good practice, but he advocates it
with a healthy dose of a bad practice -- ignoring the capabilities that
relational databases (even the limited ones available today) give you.
Constraints -- especially foreign keys -- can help database query
optimizers (and with large enough data sets, you can even partition the
data horizontally because you have useful constraints). You'd never know
this from MySQL, because it's crap all the way through, but it's true.
Additionally, just as VB promoted bad UI, PHP and MySQL have promoted
nonsense data models. I'd rather not see Rails help people further down
that direction -- data modelling is an *important* thing, and it can't
be properly driven from the object oriented side (Og's failing) and it
can't be done without proper constraint support (especially foreign
keys).
Remember -- I'm neutral about triggers and stored procedures. I have, in
fact, worked on systems where triggers were limited and where triggers
were important. They both worked well for different reasons -- but the
ultimate point behind both is that the databases were *very* well
designed and the constraints were well managed, too. It left the heavy
lifting of the business logic to the programs, but it made it harder for
ad-hoc queries to break the programs.
-austin
