From: SO

To: Editor

Date: August 15, 2003

 

I have 10 years experience as a developer and agree that the relational model is the right way to do databases. I recently completed a M.Sc. where the "weakness of the relational model" was pointed out at ever turn. It seems to me that its time the tables were turned (no pun intended).

 

Most of the criticism of Relational databases seems to come from object enthusiasts, and IMHO the best way to handle this is to point to drawbacks of object orientation. The following criticism comes from years of experience.

 

Objects are fragile There is a tendency to believe that objects somehow “model the real world” and therefore have an objective existence. This image is reinforced by the relative hegemony of Java and Microsoft libraries. Many new programmers only ever use one String class, one set of windowing classes, one set of Database classes, etc.

 

In reality objects are fragile and tied closely to a particular problem space. Java and .NET object hierarchies work only because they force users to think in a particular way. If there is no pre-existing dominant object model, different developers working on the similar problems will almost certainly develop very different solutions.

 

Object fragility is also responsible for another well-known phenomena: the wrapper classes. Corporations are forever attempting to promote code reuse and produce common shared libraries, however the author’s experience indicates that such libraries and their object models with a half-life of about 6 months. Why? The usual suspects - new users have slightly different requirements, previous incorrect assumptions are exposed, the scope of the library is expanded etc. The result is that older libraries (which still needs to be supported) are continually wrapped by newer (better?) versions. The author has seen libraries containing 6+ layers of wrappers. Of course the result is always a bug ridden tangled mess that no one understands, and the functionality that a developer wants is in layer 3 of 6 where he can’t

get at it.

 

If object models are fragile, then the ability to navigate between objects using operations is also fragile. I.e. Object networks show the same fragility Codd and Date noted in network databases over 20 years ago.

 

Application object networks are fragile, however changes to an application object model only affect application users. Changes to an object database model however impacts all users of that database. I.e. Application object fragility is generally considered acceptable but network database fragility is not.

 

So what is the corresponding relational way of programming? Many years ago I embarked on a large C++ COM project. Anyone who has done this knows exactly how tricky this type of thing is: complex object networks, changes to the design results in significant reworking of code introducing reference

counting bugs that were nightmares to find…

 

The solution adopted was to build containers for each object type and query the container to get the appropriate objects. Objects no longer held references to each other; rather they stored the names or ID (foreign keys) of any objects they might wish to access in the future. The result was a spectacular success: Reference counting bugs almost vanished and the application proved extremely resilient to changes.

 

 

Ed. Comment: Would be superfluous.

 

 

Posted: 10/03/03

 

 

 

[ABOUT] [QUOTES] [LINKS]