Karl Guertin wrote:
On 1/4/06, Gábor Farkas <[EMAIL PROTECTED]> wrote:
an interesting discussion about this "to trigger or not to trigger"
issue was spawned based in a blog entry on David Heinemeier Hansson's
(ruby on rails...) blog:
http://www.loudthinking.com/arc/000516.html
You'll notice in that article he qualifies the statement saying that
he's talking (only!) about application databases. For most of the
stuff I do at work (and apparently for Jorge as well), the database is
the lingua franca of the system, i.e. they're integration databases
and not app databases. This means that I have to spindle/fold/mutilate
SQLObject to fit with the DB relational model but it also means that I
want the triggers to fire because that kicks off the rest of the
system.
What I took away from this article is the sense that while David is a
brilliant programmer with an uncanny sense of where to ride the line on
many ideas, he's not really a database guy. In fact, I'd say he'd
probably happily agree, judging from the tone of the article. I think
his view, while interesting in a very abstract "we're not talking about
real databases with real, important data" sense has some merit.
However, I think the notion of an "application database" is a fallacy,
unless you are just talking about the database for a blog or some other
highly specific, non-enterprise type of application. The minute the
data has interest outside the original application, the minute you'll
find people wanting to access it by other means and about one minute
later his entire fallacy falls apart. Take this with the well-known
adage that data outlives applications and David's argument is a recipe
for disaster.
It's well-known that language to a large extent limits what you can
express. I think that extends to other things as well, and I think
David's argument reveals more about his MySQL-centric past than anything
else. Not only that, but his position is inconsistent with his
position on other aspects of the Rails stack. He argues that it's okay
to have code in templates as long as it's presented as a domain-specific
language, but that it's not okay to have code in databases, that they
should rather be dumb storage. He makes a distinction between
relational (database) logic and business logic (as do I) but fails to
make the same distinction between data logic (relations) and business
logic.
At the end of the day, even if David's arguments had merit, I'd still be
more inclined to trust my relational logic to the database developers
and their years of experience in this domain *and* their millions of
users who provide an ample test-bed than to one guy who's used one
database for a few years, and who, up until a couple of years ago,
thought PHP was a good language.
Sorry to rant, but he closed off comments on that blog and it's been
eating at me ;-)
Regards,
Cliff
