I spent a decent amount of time working with PostgreSQL some years ago and thought at the time that the concept of databases that could store objects was fantastic.  None of that object relational impedance mismatch hoo-hah – just save an object, retrieve an object, etc.  Unfortunately reality wasn’t so great - the tooling around reporting and support by other applications was lacking, and that plus various other influences at the time meant I didn’t really get to explore it much further and it eventually dropped off my radar.

This morning I listened to the Alt.Net podcast where Rob Conery is talkng about Object Databases (or post-relational databases as they’re sometimes called).  It’s an interesting podcast and well worth the 30 minutes you’ll need to listen to the whole thing, and it was great to hear that Rob’s sentiments reflected most of mine, though I’m sure he expressed them in a lots gooder way.

It sparked me to have a quick look at where things are at these days in the ODBMS world and to see if the critiques the SQL fans have of them are still valid.  So let me present a very paraphrased version of the wikipedia entry on the Pro’s and Con’s of ODBMS’s

Pros:

  • Performance for certain operations smashes relational databases (mainly around CRUD operations)
  • You can still add indexes for object properties to improve performance
  • Some ODBMS tools now feature SQL language support
  • No need to do object to database mapping

Cons:

  • General queries can be slower (i.e. selecting data by an entities property values)
  • Interoperability
  • May require a change in design philosophy.  Need to stop being data centric and start being domain centric in your application design.

OK, so speed can be an issue as well as interoperability.  It’s the second one that is the biggest barrier to adoption and is after all the main reason I didn’t do more with it in the past – however Rob made a comment on the podcast that really stuck; why not run both an ODBMS and and RDBMS side by side?  The two types of database engines really serve different purposes, and people already run multiple databases today with different purposes – e.g. transactional vs reporting databases – so why not do the same with ODBMS and RDBMS engines?

Here’s what the ODBMS.org web site has to say on this idea:

“Thus object databases are increasingly established as a complement to (not a replacement for) relational databases for efficient resolution of the OR mismatch. ODBMSs are flourishing as embeddable persistence solutions in devices, on clients, in packaged software, in real-time control systems, and to power websites.”

Interesting stuff and it certainly gets the mind thinking of possibilities.  I think it might be time to have a revisit of the whole ODBMS scene and see where things are at now.  I’ll probably start with the db4o database engine as it’s an open source native .NET engine with a strong developer community, it supports linq for querying (codeproject sample) and weighs in at a very light 13.5 MB.  That’s good enough for me :-)