Hey everyone-
Read the following post from a thread on Slashdot about Brian Aker's thoughts on relational & OO databases (see http://interviews.slashdot.org/article.pl?sid=07/11/28/0019253&from=rss ):
Today if you look around in the open source world you will find
examples where developers are wrapping OO layers on top of the
relational model. One of these groups is going to get tired of the
relational model and implement their own backend. Necessity will breed
the next successful model.
OO and relational do tend to
*not* get along well. They just have conflicting root philosophies. I
don't think the mother-of-invention can solve it, not without a new
philosophical underpinning coming about.
One solution is to
abandon heavy OOP and work with relational directly, another is to put
OO wrappers over relational, and the third is to use an OODBMS. Let's
look at each:
I prefer the first. I think OO does not work well
for custom biz apps and have never seen a reference implementation of
it doing well there. OOP works fairly well in systems software
(underlying infrastructure and tools), but extrapolating the benefits
of that domain to custom biz apps so far is a mistake.
The
second creates a lot of work. The wrappers/mappers become more complex
than the database itself in many cases. It's like killing gofers with
cannons. One wastes time translating back and forth between two
modeling viewpoints rather than spending such effort solving direct
customer needs.
The problem with the third is that OODBMS have
no real guiding principles. They are just a mass of virtual pointers: a
big graph of maps (dictionaries) essentially with a sprinkling of
inharitence. Similar DB's ("navigational") are what prompted Dr. Codd
to formulate relational to begin with in the late 60's. OODBMS have not
solved the original problems of navigational DB's yet.
This is exactly the kind of stuff I always heard when I talked to people about ODBMSs in the ODMG days, especially the writer's last paragraph. In the 90's, many ODBMS vendors thought they were going to "get Larry Ellison's house," i.e. they were going to replace relational DBs in enterprises with ODBMSs. I never believed in this goal, because it would not have made sense to replace SQL with C++ (unfortunately the lingua franca of OOP back then). This would not have made sense because to replace one or two SQL statements might have taken dozens (or more!) lines of C++ application code, and the end result would have been far less readable, maintainable or portable than the SQL in many if not most cases.
This is why I believe Prof. Subieta's work is so important: it addresses the missing theoretical foundation for ODBMSs. We may have to add to what he has done, but he is addressing what I see as the core problem for the adoption of ODBMS technology.
If we give in to our "inner geek" and dive straight for Java/C#/whatever APIs without getting the semantics, definitions and models right first, we will just repeat history and re-do what ODMG already did. Every vendor in ODMG thought they had the best native OOPL APIs. After all, their customers were all happy! But in the end, code written to those APIs was not portable and so the market for ODBMS technology never really grew because a customer had to "marry" a vendor: your code was truly "'til death do us part!" And the ODMG "standard" did not help this because there were too many "holes" in it where crucial semantics were not specified due to varying implementations among vendors (for example, when you commit a transaction do native pointers to database objects get cleared or not?). Portability was only one problem of course, there were also scalability issues for some products and a lack of understanding of the database marketplace in others ("we don't use keys, that's a relational thing! OO people use iterators to find things!" Yes, I was actually told that once).
OK, I'll climb down now! ;-)
Hope to see you all in Burlingame!
-Mike