On Mon, May 28, 2007 at 09:37:53PM +0200, Lukas Kahwe Smith wrote:
> inside the database. Which is all kind of ok, as long as you never mess
> with the database through anything but your single middle tier
> implementation.
That's a pretty big if. It's part of the reason I really dislike the
idea of moving integrity work out of the db and into the application.
For it's not only ensuring the data only gets updated by the
application that you need worry about; you also have to make sure
that all the application programmers (and there will be more than
one, for any application that lasts any length of time or does
anything non-trivial) do all the integrity stuff in the same way.
And they rarely do. The whole point of centralising your data is not
only to share it; it's to share it in a consistent way. Otherwise,
why not just dump it on the filesystem?
> My point is, there are solid reasons for writing applications that use
> the database as a mostly stupid data store with very efficient retrieval
> and these applications tend to also perform pretty well regardless of
> what RDBMS you stick underneath.
RDBMS are often not actually very efficient retrieval engines. If
that's what you need, straight filesystem access is a better bet.
The _R_ in RDBMS is there for a reason, and if you're not going to
use your database in a relational way, then you don't need an RDBMS.
You _can_ use the RDBMS as a mostly stupid data store, and it likely
won't break anything. But it seems a waste of computing cycles to
me. Often, the "stupid datastore" systems I've seen look like
they've used SQL because that was the hammer the programmer had,
rather than the right tool for the job. (This is optimising for
developer learning curve rather than anything else. Also a
legitimate trade-off, if you want to make it, so long as you know
you're doing so.)
A
--
Andrew Sullivan | ajs@crankycanuck.ca
I remember when computers were frustrating because they *did* exactly what
you told them to. That actually seems sort of quaint now.
--J.D. Baldwin
