Understanding Object Databases

Object databases such as Objectivity/DB, Poet, and Matisse started appearing in the 1980s as a proposed alternative to transaction-oriented relational database management systems. The idea was to treat data more intuitively as objects (Customer and Invoice objects, for example) instead of as a series of flat rows that have to be stored in tables and related via foreign keys. (For a good overview of object databases, see Doug Barry's site at www.odbmsfacts.com/articles/object-oriented_databases.html.)

A simple way of thinking about object databases is looking at how you would create a simple program that shows a list of all the users in your database.

Using SQL to get this data from your relational database, you would use the following statement:

 SELECT * FROM Users 

You would then have to take the data returned from the query, transform it into objects in your code, iterate through a list of users, and display the results. This is a hard-nosed look at the problem; technically you can just pipe the results directly out from the database, but in doing so you give up the encapsulation promised by object-oriented programming.

Using an object database, your code would look similar to the following statement:

 Dim users As Users() users = open('users').Load() 

For listing all users, the object database wins in terms of simplicity. The data is acquired, and it's already an object with no need for a transformation to work with it. All you would need to do then is loop through the collection of users objects.

It gets a lot more complicated when you want to perform a "reporting" type of function on the database such as getting the total amount of orders to be shipped on a future date.

In SQL you can use the following syntax:

 SELECT sum(Amount) FROM OrderedItems WHERE ShipDate > GetDate() 

With an object database you would have to actually loop through all of the items in the OrderedItems collection and add each amount to the total. There are other options that different object database vendors support for summarizing data, but the options overall are not as simple and consistent as they are with SQL tables.

Ultimately, object databases never caught on for a variety of reasons. Some people feel strongly about to say that object databases are inferior to relational databases, but in the end the marketplace has spoken and the number of object databases in actual use in production systems is tiny.

So, although it's unlikely you'll ever run into a project that uses an object database, you can still work with objects in your code that store their properties in a database transparently, which allows you to focus on developing new functionality instead of worrying about breaking old code.