Re: Way to go, David!

David,

> In a word: They're a huge PITA for object-oriented design. "The
> object/relational barrier is a well-known impedence mismatch," as Ziggy
> noted in a comment on my entry, and that's the crux of the problem to
> me. Make no mistake, PostgreSQL is hands-down my favorite database, but
> I wrote that entry to be deliberately provocative. The relational model
> is good for some things, but nothing that I do. So I want to challenge
> people to come up with a better solution. I'm not optimistic.

Well, let's clear some stuff up.

First, SQL is an imperfect implementation of the Relational Model. Second,
actual RDBMSes are imperfect implementations of the SQL standard. So dealing
with any real RDBMS, you're at least 2 levels removed from "pure"
relationality. In your case, you are in fact 3 levels removed, because of
maintaining Bricolage's "database independance", which means that you have to
support all of the most annoying limitations in all RDBMSes. In other
words, if the Relational Model represents the ideal database at 100%, you're
at about 9%. So I'm not surprised that you are aggravated.

I would argee with you completely on one point: If your purpose in a database
is to act *only* as a persistent object store, then you need different
technology. From my perspective, though, that design strategy is like buying
a sports car and then never letting it out of first gear ... you wonder what
the heck you spent all this money on.

I'm also not a fan of Postgres table inheritance; I feel that it's a hack and
has no place in a SQL database. Many disagree with me, though.

There are a lot of things that SQL-set logic does a lot better than OO --
particularly enforcing data integrity rules. SQL, for all its faults, has
had 24 years of development as a standard; that's not collective wisdom to be
thrown away lightly.

More to the point, the advocates of OODBMSes have been chronically unable to
develop a standard, due to a combination of vendor infighting and the lack of
a suitable body of theory to support the OODBMS model. For example, the
"standard" most often used to promote OODBMSes is UML ... but UML is not a
standard; read 3 UML books and you will be exposed to 4 different theories
and 5 different sets of terminology. This lack of theory is perpetuated by
some OO vendors ignorance of, and casual disregard for, CS theory in general.

So it would be really nice if someone developed a standard for OODBMSes as
persistent object stores. But it won't happen for at least 3 years, if then,
and even such a future standard will be unsuitable for apps which are the
mainstay of SQL ... such as accounting, transaction processing, and data
mining.

In the meantime, Fabian Pascal and CJ Date are working on the next-generation
*relational* database -- TRDBMS. In the absence of a useful OODBMS
standard, I think you may find that many of the object/relational interface
problems evaporate with an improved relational database as well as an
improved understanding of it.

--
-Josh Berkus
Aglio Database Solutions
San Francisco