Object oriented databases. You either love them or you hate them. Like much that goes on in the IT world, the battle lines have been drawn and it is fought out much like the crusades of the middle ages. It has turned into a religious war.

I’ll tell you where I stand at the outset – I don’t like them. Although I have to admit, that some of the reasons I don’t like them are difficult to put into words. It may be that I am old and cussed and opposed to change.

Back in the 1980s (I told you I was old) I wrote a sort of object oriented relational database. I thought it was the ant’s pants of database design. The reason I did it was because of one of the tenets of OO design – encapsulation. I built a database structure where all the data and all the methods and properties associated with the data were encapsulated within the database. It made sense to me.
Unfortunately, it didn’t work very well. Part of the problem was that I was just learning to write in C++ and that is not a language that you learn when you have a spare afternoon to fill in. I’m sure that the major problem was my bad coding.

But even after tweaking my code to make it work better, or even just work sometimes, I came to the conclusion that encapsulation, at the database level, was not a good idea.
If you are writing an application to sit on a desktop and everything will be used locally it doesn’t matter too much. You can mix the program with the data and no one will be the wiser. Until someone needs to maintain your code and sees the mess you have made and then you look like an idiot. But if it is all running locally then you can mix it up, it will run just the same. I don’t recommend this approach, if for no other reason, because it is almost impossible or at least very difficult (translation – expensive) to maintain.

But once you have more than one user accessing your data the everything changes. The usual model is to separate the components into an n-tier application, where n is as big as you like, but if it is too big then once again you look like an idiot. What are the tiers? Usually there is a data layer, perhaps a business layer and an application layer. These last two can be further broken down if needed.

And what normally happens is that the data layer sits on a server, or in peer to peer networking it will sit on one PC which acts as the server as far as the data layer is concerned, and as far as many other things which don’t affect us here are concerned. The application sits on each user’s computer. And the business layer? I have called it that because that is often how it is described, but, and remember it may not even exist, depending upon what it is and the size of the system, it could reside in one of a number of places. For example, one model for large enterprises with large applications is to have the business layer sit on a separate server. Enough of the business layer. It is not really relevant here and I won’t refer to it again.

Assuming we are using an object oriented approach, the question then is, where does the encapsulation occcur, within the application or within the database? The former model uses, usually, a relational database. The application grabs the data and creates an object out of the data. In the OO model the application grabs the object from the database. You can see that both are doing the same thing, it is just a matter of where everything is going on, sort of. And you can probably see why I liken it to a religious war.

I should add that there is much more to OO than just encapsulation, so if you are an OO zealot please don’t tell me I missed all the good stuff, like inheritance and polymorphism, they are more fun than sex and more exciting than a roller coaster.

There are a thousand and one reasons why you should use an OO database, according to its adherents. I can only look at one. The claim is made that objects provide a more realistic model of the real world. That is, you can create objects in your application which are a much closer representation of the real world objects which your program is dealing with. This may be fine for some objects. One of the oft quoted examples is Comuter Aided Design, CAD. The objects which comprise a CAD drawing don’t easily fit into the relational model, but are perfect candidates for OO, or so the argument goes. That may be right. I have never programmed anything remotely resembling CAD or built a database to deal with CAD objects.

Perhaps my thinking is coloured by the type of programming I do. Most of it is small to medium sized applications for small to medium sized businesses. What are their real world objects? A transaction, a customer, an order – these are the common objects they deal with every day. And encapsulating all the object properties just doesn’t work well.
For example, if I wish to create a new customer within an OO framework using a relational database then I need a class, we will call it customer. The class has a constructor (it probably has quite a few) so that I can create a new object to represent the new customer. Within the customer class I have a method called, say, SaveNew which contains the SQL statements to add a new customer record to the customer table of the database. I could do exactly the same with an OO database. The SaveNew method would be part of the database structure. And this seems appealing. Isn’t adding a new customer a fundamental operation? Once I have built the database I never need worry about how I add a new customer. I merely call the SaveNew method which is contained within the database. How it does it remains hidden, only the call to the method is exposed.

But that is exactly what happens by building a class and having the method contained within the class. The bigger problem arises when I wish to update a customer record. Once again I can build an Update method. And this works fine if I am updating every field. But in the real world, which we are supposedly modelling, this is not what happens. There are times when we only wish to update one or two fields within a record. It is then much easier to write the SQL call in the application and by-pass the customer class altogether.

This is just one example. But the bottom line is that I cannot get around the notion that it is much safer and more efficient to separate data from its methods. I will continue to put data in a database, and the methods in the application.