Object Persistence ??

In software development, programming only represents half the problem, the other problem is storing and sharing data across users and other programs. The Object oriented paradigm expands the meaning of “data”. Object contains methods, complex data structures and references to other objects. This can’t be easily stored in a relational Database.

Although it is possible to store objects in a relational database, we can’t overlook the underlying conceptual differences between the relational and object paradigm. This is common know as the impedance mismatch .

we can define objects in terms of classes and create hierarchies of these classes, now to effectively store objects, a database must be able store inheritance hierarchies and create instances of these classes using this information. Relational database were never designed to handle hierarchical structures like this. As Developers we spend a lot of time to work around these limitations to try and make it all fit, knowing very well there is an obvious  underlying mismatch. Let take a very trivial example, suppose we have an Address class which was mapped to an Address Table. Now suppose there was a requirement to handle new types of address which contained an additional field. On the object level we could create a subclass of Address and define an extra variable to hold this additional field. Now on the relational database we would typically create another table to hold this additional information with a link to the Address table. Now this requires construction an object from multiple tables, now as the object structure get complex this can be very time consuming.

Most object oriented designs contain composite objects and usually there are complex patterns of interaction between these objects. Objects hold reference to other objects, to allow fast navigational access. Relational databases on the other hand can also handle these nested structures but they have no references so navigational access is not possible but they have is associative access which based on matching data, this process is very slow and depending on the complexity of the nested object structures, this can be a time consuming process. A study done by the US navy showed relational database are 100 to 1000 times slower than a database that can provide navigational access.

As mentioned before the object paradigm expands the meaning of “data”, one of the fundamental characteristics of Object Oriented design is encapsulation. Objects contain methods as well as data, this means storing methods and data as one package and maintain cohesion between the two. Generally relational database cannot support this, relational databases have stored procedures but this is usually programmed using Sql (Original intent of SQL was never intended for programming but to be used by the end user). This is always different to the programming language used to implement the objects.

In my opinion relational database introduces barriers to object thinking, objects allows us to think in terms of real objects such as customer, products, items. When they are stored in a relational database they are dissembled into different tables. rather than thinking about the domain model, we try to design our object model so they can be chopped up later into some low level data which bears little resemblance to the original object just so they can some how fit into a relational database. This is the same as having to disassemble your car every time you wanted to park it in your garage. Not only that you stored each part in a different garage, you have a garage where every body put there car wheels, another garage where every one stored their car body. And when you want to use your car again in the morning, you had to go to each garage identify the part that belong to your car, then assemble it before you can drive your car again, how painfully inefficient, but this is essentially what happened when we store Objects in a relational database.

O/R mapping are great for some problems (check out GLORP) but really they don’t solve the underlying impedance mismatch problem, it might insulate the mapping from the developer to a certain extent, but really you still disassembling your car before parking in the garage, its just being done by someone else.

Can a Object Oriented Database provide the perfect solution ?


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s