Objects vs relational tables

A while ago, I came across a whitepaper published on the Internet:

" The Failure of Relational Database,
The Rise of Object Technology
and the Need for the Hybrid Database".

The paper tries to give an explanation of objects vs relational tables. I quote from the "whitepaper":

"Consider the automobile as a complex object. When you use an automobile, you use it in its entirety, as one thing - a s an object. Associated with the automobile are many activities (methods in OO terminology).

You steer a car, you change gear, you signal, and you turn the headlights on and so on. (My comment: And on a bicycle...?)

If the car is an object, these activities are the object’s methods and they are fundamental to the car. (My comment: Not to bicycles/scooters/trains/whatever moves?) The idea of these activities being independent of the car is ridiculous.

When you put your car in a garage, you store it as one thing complete with its capabilities. You don’t put your car in the garage and store its steering, transmission, signaling and lighting functions someplace else. Data and its associated processes cannot and should not be separated, and in object databases they are not."

In short: BS.

The "whitepaper" wants us to believe that data and processes belong together, and cannot be separated. If that holds, what comes first: The Data or the Process?

But let us take a closer look at the claimed benefits of objects vs relational tables:

A car is a complex object, consisting of smaller parts (objects?). Among those parts are signaling and hence the process of signaling. Can't signaling (a process) exist without the car?

Of course it can. Actually, signaling was non-existing on earlier cars, until signaling rules were prescribed. This process then had to be adapted by all cars. The process is the same for all cars (and any other kind of vehicle). Why should it have to be encapsulated with each car?

The gearbox was invented long before we had cars. It was very practical to use it in cars when they were invented. Today, there are few manufaturers of gearboxes and brakes. Such parts are very much standardized, and the same parts can be used by many brands. I know. I just recently had to change the brakes on all four wheels.

When it comes to objects vs relational tables, I do not think it sounds ridiculous to separate data and processes. What if processes change? You would still want to use the same data.

And what last longest? Data or process? I predict that in 20 years from now, the processes for paying out my pension have changed. I (or rather, my identity) haven't. (You know what I mean: My SSN is the same)

And of course you store your car in your garage as an occurrence of an entity, in other words as a particular car. But: In a relational database, I would believe that you had an occurrence for your car? Just like the whitepaper on objects vs relational tables assumes for its cars?

The difference between persistent objects (the car is an object) and a normalized relational table ( the car is an occurence of a row in a table) is as follows:

According to the whitepaper, if the manufacturer finds a serious production defect on the brakes, or launches a major improvement, he will have to call in all cars (update all objects) to the nearest auto service shop for immediate repair. He would also have to call inn all drivers, all allowed passengers, and every other aspect related to the car. It would take a lot of resources to accomplish that.

According to the relational model, the manufacturer updates the specific brake parts at his brake plant. He only has to make one occurrence of each part. He puts each piece on its shelf (a row), and goes home to sleep.

The next morning, since all cars are put together when needed, all cars that use this specific kind of brake are done the instant you open the garage door. The foreman (DB system) is putting his top mechanic (some optimizer) to work the millisecond when I grab the door handle, and before the door starts to move, an updated specification is fetched from the shelf of the brake supplier, and the car is ready assembled.

Imagine: Each morning I have a new and improved BMW in my garage!

How's that for the drawbacks of objects vs relational tables...

The same applies for atomic bombs :-), but not in my garage!

BTW: This article also coincides with my article on Atomic values. As you can see, an atomic value (a column) might be an array, or even a table! So much for objects vs relational tables... Ignorance rules.

Return to Database Theory and Practice