Older Twocentsworth.com Archives


RDBMS != Object Store

This Slashdot comment just might be the most informative and eye opening thing I’ve ever read in 3+ years of slashdot addiction. Here’s the poster’s summary:

“There is an insoluble tension, or impedance mismatch, between OO and RDBMS. OO is about classes with structure and objects with identity. RDBMS is about relations bearing tuples satisfying predicates. OO lets you pass around structure, data, and behavior by handing someone a pointer. RDBMS lets you derive new facts (in new structures) from known facts.

These are not the same kind of thing, and there exists no natural mapping from one to the other. Anyone who tells you otherwise is selling something. If you want an object store, get an object store; if you want to store facts and derive other facts from them, an object store will not help you — you need an RDBMS. “

My own knowledge of the OO ideology is still relatively young, but since my introduction to some of it’s common design patterns I’ve struggled with the seemingly forced RDBMS object storage idea. Now, I think I need to look further into the realm of object stores beyond RDBMS’s. If this isn’t news to you please feel free to drop some hints as to where to look for alternate OO data stores (especially in terms of stateless web application development, if such a thing exists??)

It’s very late and I’ve had way too much caffeine today so I hope this all still makes sense to me in the morning.

Originally published on RDBMS != Object Store'">Wednesday September 24, 2003 at 3:04 am

[4] Comments

I agree to some degree, there is a definite mis-match between OO and RDBMS, but there are enough similarities between the two that allow you to use an RDBMS to store Object Data, you know this from your experience as a developer of OO web applications. NOTE: Object data is not an Object, this is the key difference in my opinion. The writer of the slashdot article makes very good points "there exists no natural mapping from one to the other", true, but an un-natural mapping can exists in the form of a well defined relationship between the RDBMS and one or many objects in your system. The issues arise when you need to change your object, or your RDBMS, you then have to do regression analysis to verify that your modifications will not negatively affect another part of your system. Your knowledge of OO is more mature than you realize, sure there is always something more to learn. As far as OO data stores and web application development go, you don't need an object store, you are more than capable of maintaining a strong relationship between your objects and your data, I've seen it. Here's an example of how an Object Store falls apart in onw of your applications:

Say your building an ecommerce site and you store order related data, Order, Order Address, Order Item, etc. In an object database these this are object with string relationships: Order has 1 to many Order Items. Say you need to create a report showing the total number of each SKU in the system that has been sold. In an OODBMS you must instantiate each order, get its items, and count them. If not designed properly, when you instantiate each order, the order items, order addresses, etc may all be instantiatied as well. This is overhead, not tomention that enumerating each order and order item could take some time. In this situation an RDBMS is far more flexible. One query can return the all the results you need. I could write forever, but hopefully this has been valuable to you.

Kevin Saffer said this 17 years, 9 months ago §

Kevin pretty much sums up what I'd say, but maybe I can add a few thoughts.

The article seems to compare object stores and relational databases. This is not the same as comparing object-oriented programming and relational databases. If I'm right, an object store is another term for an object database. The benefit of an object store is that I can write my application using object-oriented techniques and store the objects' states directly. With an RDMS, I have to store the objects' state indirectly by converting to the source table(s).

It's worth noting that in a system where the code is object-oriented and the source data is RDMS, the classes don't have to correspond to the tables (though they often do). An object will often have may properties that don't exist in the database. Some of these properties *are* deriving facts from known facts, such as a property "Extended Total" that is derived from Qty * Price.

Where I appreciate Kevin's comments is that he doesn't take the black and white position that the articles author does. It's true that an object store and an RDMS aren't the same. It's somewhat true there's no "natural" mapping. But that isn't to say that they can't be mapped, or that there's no useable relationship between the two. An OLAP database (OnLine Analytical Processing) isn't the same as an OLTP (OnLine Transactional Processing) database, but there's a relationship between the two (the OLAP cubes are derived from one or more OLTP databases). As a matter of practice, I'd expect to see both an Object Store and an RDMS in a larger business. Doug Williams has an excellent story of a business who improved their billing process by implementing an object database.

This brings me to a final thought. The article's author implies "choose one or the other." If that was the intent, I'd have to disagree. An Object Store is going to be very efficient for some data uses, and RDMS very efficient for others (as the author correctly states). But *both* may need to deal with the same data. This means a mapping, however unnatural, must exist between the two data stores otherwise the data itself isn't guaranteed to be consistent.

From what little I know, object databases are very interesting and impressive. I think the author wants to emphasize the point "the right tool for the job", with which I agree. But unlike carpentry, we don't just use a saw to cut and a drill to make holes and in the end we have a table. We take a painting and pull it apart in various useful ways and store the pieces in one place or another, but ultimately have to be able to reconstruct the same Van Gogh.

Charles L Flatt said this 17 years, 9 months ago §

Preview: Two people have posted comments since I composed mine, so there will probably be some duplication of ideas.

As you probably guessed, I have a few issues with those points.

"OO is about classes with structure and objects with identity"

This is only part of the truth. A class is data (structured) and methods which act upon the data. Data and its behavior, if you will. A RDBMS is about data and its relationships without behavior (although, as a side point, SQL does provide behavior, but it isn't as tightly coupled to its data). Both are about data!

"These are not the same kind of thing, and there exists no natural mapping from one to the other. "

A very emotional argument. Define natural? Relationships in an RDBMS are defined, but additional relationships can be quickly created and managed (both temporary through queries and permanent through foreign keys). OODBMS's also have relationships -- through collections and within the objects themselves. However, it is a tight coupling and adding relationships (however temporary) involves writing and compiling code.

"If you want an object store, get an object store; if you want to store facts and derive other facts from them, an object store will not help you — you need an RDBMS. “

I disagree somewhat, but what this is about is efficiency.

An OODBMS already has its data relationships predefined -- so accessing information around those predefined relationships is much faster then accessing these relationships through an RDBMS. However, if you want to look at different relationships that aren't predefined -- an RDBMS is much faster then with an OODBMS.

A few interesting notes:
The author conveniently left out ORDBMS -- tries to be a hybrid -- the data is in tables but the rows have behavior :)

Some ORDBMS have RDBMS interfaces -- the data is actually stored in tables (each type has its own table) -- and can be queried. However, these queries aren't quite as fast as RDBMS.

It isn't uncommon for objects to serialize their data into a database. Why, some crazy coders even use an object layer on their web sites -- the objects main purpose being to easily access and manipulate relational data! Crazy I tell you!

Finally, money can't be forgotten. A RDBMS tends to be cheaper the an OODBMS -- in purchasing, creation, and maintenance.

Doug Williams said this 17 years, 9 months ago §

Wow. Thanks for the comments guys!~ I'm glad I emailed to ask for your thoughts.

After a few hours sleep, filled with dreams of RDBMS and OO programming, I awoke to find some great discussion and amazingly it all still makes sense to me.

Aaron said this 17 years, 9 months ago §

Comments were disabled for this post. This happens for a variety of reasons and most likely it's not your fault. Unless you're a spammer. Then it might be your fault.