Hibernate’s Gavin King recently published A Defense of the RDBMS. He has several useful points about ORM and object databases and their as-yet lack of success. Perhaps the most salient point is in the conclusion, however.
If you think that relational technology is for persisting the state of your application, you’ve missed the point. The value of the relational model is that it’s democratic. Anyone’s favorite programming language can understand sets of tuples of primitive values. Relational databases are an integration technology, not just a persistence technology. And integration is important. That’s why we are stuck with them.
Every non-trivial project I’ve ever worked on that both used a database and was more than a startup’s website had multiple programs accessing the database.
Actually, that’s not true. They all accessed the data.
The features of the relational model–especially correctness, coherence, and lack of duplication–help preserve the integrity of that data across applications. Arguing that the application layer is the proper place to enforce constraints (as I’ve heard from some ActiveRecord proponents) is like arguing that wrapping binary data in a a pair of XML tags is advantageous for office documents.
If and only if your application is the only one that will ever access the data, perhaps that’s the right choice… though why are you using a relational database in that case?
I generally agree with the author, save for one concern: "almost every ORM solution on earth has the capability to automagically forward-engineer a schema from an object model"
Most "automagically generated schemas" I have seen initially work fine for the original consumer, but become problematic as soon as their data becomes valuable enough to be targeted by other applications (reporting/analytics are common here). By modeling the schema from a set of objects, instead of defining the data independently and logically, some unpleasant messes can be created.
"why are you using a relational database in that case?"
Because it's a readily available, well-understood, networked, transactional storage system. Why make another one?
Well, in the relatively recent past, you had a choice between persistence with an RDBMS manager such as MySQL (with the added overhead of a separate server), or rolling your own persistence mechanism by extending BDB and related mechanisms like python shelve. The middle ground between these two has been lacking in tools.
Where things like db4o, prevlayer, and elephant (for common-lisp) have an advantage are cases that require something more complex than BDB key/value mappings, but a full RBDMS with client/server capabilities is overkill. That additional layering is useful when needed when not needed it just gets in the way. The bottom line of Mr. King's rant is that object databases fail for the kinds of multi-client, multi-application problem domains that MySQL and Oracle have pursued. Which is fine, but I don't think that every application that works with data needs to be multi-client and multi-application.
I think that Mr. King is either overstating the case for the "automagical ease" of ORM, or does not fully understand the limits of ORM. In my case, I needed bi-directional one-to-many relations, which the hibernate documentation admits is difficult, and apparently accounts for a large number of support requests. Using hibernate against HSQLDB, I repeatedly failed to get a working schema, even working through the copious documentation. Using db4o, I was able to do it using just ObjectContainer.set(object). I suspect that ORM works "automagically" for simple cases. More complex constraints might require some painful mapping indeed. (And this was working with a brand-new database.)
To be honest, I'm finding a lot of the rhetoric involved here to be depressing. No, object-oriented persistence mechanisms such as db4o are probably not going to challenge RBDMS for the multi-client, multi-process server space with data storage expected to exceed 20 years. On the other hand, RBDMS may not be the best choice for single-user solutions that juggle smaller datasets.
Also, I find the 5,000 year archeologist argument to be amazingly silly. The archaeologist will have to figure out how to parse the tables used by Oracle or MySQL as much as the key/blob mappings used by object persistance mechanisms.
And in particular, MySQL, elephant, and shelve all can be configured to use Oracle Sleepycat, with complex objects stored as numbers and strings.
On the other hand, RBDMS may not be the best choice for single-user solutions that juggle smaller datasets.
lookit SQLite http://sqlite.org
I use it in all sorts of stand-alone scripts, except for the most rudimentry.
The relational database needs no defense
Christof Wittig, CEO of db4objects