Relational vs Object Oriented Databases

People often think of an employee's productivity as a function of their job satisfaction (those who like their job will be more productive), but based on my day to day experience I'd contend that the exact opposite is true: my job satisfaction is a function of my productivity.

Today I spent the majority of the day wrestling with an ORM tool, and I didn't get very far, and as a result I don't like my job very much right now.

This is a particularly painful mar on my workplace happiness because of the very positive experiences I've had recently with DB4O (Database for Objects), so I'm going to compare and constrast a little bit to vent my pain.

Writing the data layer

Usually when you're writing an application on an enterprise level, you're going to have to write some sort of intermediary data access layer in order to transform the data in your storage medium into the business objects that get passed around the rest of the application. When building an application (in an OO paradigm) with a relational database, you have several steps to go through.

1. Get a database instance up and running.
2. Create the tables you will use to hold your data.
3. Define the relationships between those tables.
4. Code the objects that will represent your data in the application.
5. Write all the code necessary to take an instance of each entity object and shred it's state into the correct tables in the database.

After all that, you can get down to the business of putting together an application to deal with that data. Despite the fact that it only took 5 steps to deliniate, this can be a pretty painful process, and it is exponentially more so the bigger your object model is. There can be hundreds of lines of code just dedicated to the task of sending data to the database.

Now, when you want to start a new application using DB4O, here is your data layer (my examples for this article will be written in C#.Net):

 IObjectContainer db4o = Db4oFactory.OpenFile("[filename].yap");
 Person person = new Person("Ethan Vizitei");
 db4o.set(person);

That's it. That object is now stored in a working database. If that file specified doesn't already exist, it is created, and each object you send to it is saved as-is. I don't have to write anything to map the fields to another medium, I don't need to build complex DAOs and write a lot of iffy test cases around them. It just works.
This should appeal to anyone who doesn't want to consider OO databases because they hate having to master new technology. How much easier could that get?


Querying for data

Ok, now that we have something stored in the database, I want to extract data that's previously been persisted.

Working with an RDBMS, I'm going to have to generate some SQL one way or another. What I WANT is a set of objects that meet a certain criteria, but what I have to DO is open the code in my data-layer, look up what fields in my objects map to what data in the database, and write some SQL to do the work.

How would an object database handle this? Let's say I want to find all the people who work in the IT department at my company. I have an object "Person" with a property called "Department". I could do this one of a couple ways. I could query the DB4O file with an example object:

  Person prototype = new Person();
  prototype.Department = "IT";
  IList people = db4o.Get(prototype);

or I could just write a predicate:

  IList people = db4o.Query(
    delegate(Person person)
    {
      return "IT".equals(person.Department);
    }
  );

Either way I now have the list of people I wanted without any extraneous work. It's all done with objects, which is the natural way a programmer is thinking when he's working in an object-oriented paradigm. Your data IS an object, not a flat representation of an entity.

If you're a java or .Net developer who sees the development savings inherant in NOT spending a third of your time writing data-access code, consider giving db4o a shot on your next prototype. It's at least worth a once over if you haven't tried it before.