When I first read about Drizzle last week I assumed it was some kind of joke. It turns out that it isn’t, so it just makes me a little depressed.
Drizzle is[1] a cut-down version of MySQL. MySQL is the database server than has been known to make grown database designers cry because of its rather cavalier approach to the relational database model. For much of its existence, MySQL didn’t have many of the features that make databases useful – features like triggers, stored procedures and (specially) referential integrity. It was very fast, but it really couldn’t be described as a relational database. It was just a data store with a vaguely SQL-like query languge. Over the last few years, MySQL has added more and more of these features and recent versions are very nearly like a real database[2].
Of course, adding these more advanced features is going to effect the performance of the database. If you’re checking referential integrity on each insertion, then things are bound to get slower. Or are they? I’m not sure that’s the case. If you don’t use the referential integrity checking in the database then you have to duplicate that functionality in your application code. But checking referential integrity is a core feature of a database system. That code is (hopefully) going to be well written. In most cases it’s likely to be better than your code. So trusting the database to check referential integrity is likely to make your application seem slower until you turn off your own hand-crafted referential integrity code. Trust your database to do the work. It’s what it’s best at.
But I think the damage has been done. There is a generation of database designers (and I use the term in a very loose sense) who don’t know about “advanced” database features like referential integrity, triggers and views. They don’t know about them because they learned database design whilst using an older version of MySQL which didn’t have those features. Or they learned from someone who learned whilst using an older version of MySQL. We have systems like Activerecord which encourage the developer to ignore the advanced features of the database and to use it as a dumb data store.
So this generation of database designers don’t see the need for these features and therefore don’t use them. They see them as an unnecessary waste of resources which just slow down their application. In my opinion, if they learned about these features then they wouldn’t think like that, but I’m not writing this entry just to plug my Advanced Databases for Beginners course.
I don’t deny for a second that many applications (mostly web sites as far as I can see) run really successfully without using these features. But as a database designer it makes me nervous. It’s like programming without a safety net. Why take unnecessary risks with your business data?
So this is the perceived need that Drizzle addresses. A need for a dumb data store that doesn’t do any of the advanced things that a database should do. It’s like we’re turning back the clock to MySQL 3.x. And that’s why Drizzle depresses me. It looks to me like a dumbed down tool for people who haven’t taken the time to learn their craft. I spent far too much time working with MySQL 3.x. It always ended badly?
Am I missing something here? Perhaps I’m a “database dinosaur” who just doesn’t understand the new trends. Please point me at at articles that could enlighten me.
But until you do, my databases will all include referential intergrity, triggers, views and stored procedures.
[1] Or, more accurately, will be. It’s a work in progress.
[2] Athough you still have to entertain doubts about a database system which documents an option (and one that is off by default) which makes it ‘behave like a “traditional” SQL
database system’.
Drizzle uses InnoDB only, which means that it supports foreign keys and the corresponding referential integrity features properly out of the box. It’s more about massively decreasing the complexity of the MySQL source code than it is about dumbing down the database – they’re prioritising the features that people actually use. It looks like triggers will be relegated to a plugin (Drizzle is designed to be massively extensible using plugins) but there’s a reasonable chance that materialised views will make it in, which makes sense as they’re a powerful tool for performance improvements via controlled denormalisation (which is the kind of thing many people use triggers for).
I think this is the natural consequence of the extreme programming adage “do the simplest thing that could possibly work”, writ large.
Many software developers are under pressure these days to deliver things based on technologies they barely have time to come to grips with. Consequently, apparently ‘simpler’ technologies can seem to be natural choices, because you can grasp what they’re for, and how to apply them to your problem, more quickly than their complex counterparts. When your understanding of databases is at the level of “pile of data”, a tool that presents you with a similar metaphor can actually look like the right one for you, even if it’s really just your ticket to the debugging casino.
Of course, there’s ‘simple’ and there’s ‘naive’; one of the perils of being an experienced developer in almost any non-trivial domain is that you can foresee how these ‘simple’ systems often have failure modes that, as you say, can jeopardize the integrity of your data, as well as causing many actual problems. In other words, you’re doomed to be Cassandra Q Developer, much-ignored CEO of ‘I Told You So, Inc.’.
Sadly, I don’t see a way around this problem, other than learning how to dodge their wayward bullets, gnash your teeth more comfortably, and walk tightropes without rollback recovery.