Date: May 29, 2003
From: SO
To: Editor
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 impact 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.
Fabian Pascal Responds: The question is are
those weaknesses, or just lack of knowledge/understanding of the relational
model? I suspect the latter, in which case the tables are not turned,
except perhaps in a very trivial sense.
By no means does criticism come only from object enthusiasts.
It comes from those who do not know or understand data fundamentals in general,
and the relational model in particular, which means a majority of the industry.
Anyway, OO has little to do with databases and, therefore, criticizing OO as
such is getting mired into fuzziness and irrelevancy. To the extent that object
proponents criticize the relational model, it is incumbent on them to prove their
claims, not the other way around. Nevertheless, we did demonstrate the
weaknesses of OO for data management quite often (see references), and others
question OO more fundamentally (see Object Oriented Programming
Oversold!).
The logical conclusion of lack of education in fundamentals
is the widespread “cookbook approach” and almost exclusive reliance on products
and vendors for information and knowledge. Anything not product-specific is
deemed “theory” and, therefore, not practical. Not only is foundation knowledge
not rewarded, but is actually punished, and today you cannot get it even in
universities if you wanted too.
What you describe as “object fragility” is the very thing
that Codd wanted to eliminate when he invented the relational model. The
problem is that OO is a programming approach and, therefore, ODBMS is
the concept that an application programmer (without database knowledge) has of
what a DBMS is. Putting database management back into application code explains
the fragility (that is also why ODBMSs are DBMS-building kits rather than
DBMSs). OO also brings back pointers and hierarchic navigation, throwing us
back decades (Those
who don't know (or forget) the past are condemned to repeat it).
Since the relational model is a data management, not
programming approach, I do not know what “relational programming” means
exactly. Another objective of the model was to minimize application
programming altogether, by having the DBMS handle database functions
(integrity, concurrency, security, and so on) and leave only application
functions (presentation and communication) to applications and, thus,
programming. To get a sense of how that is achieved with a true relational
language implementation, see On Declarative Integrity
Support and Dataphor.
References
OO for application development, not database management
ODBMS vs. TRDBMS - Reply to Barry
Oh, Oh not OO Again
Objective Objectivity? Reply to
Guzenda
Posted 09/05/03
[ABOUT]
[QUOTES]
[LINKS]
