Skip site navigation (1) Skip section navigation (2)

Re: Way to go, David!

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: David Wheeler <david(at)kineticode(dot)com>
Cc: SF Postgres <sfpug(at)postgresql(dot)org>,Dave Rolsky <autarch(at)urth(dot)org>, Adam Turoff <ziggy(at)panix(dot)com>
Subject: Re: Way to go, David!
Date: 2003-05-30 19:12:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: sfpug

> 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 

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

In response to

sfpug by date

Next:From: eleinDate: 2003-05-31 04:13:22
Subject: Re: Way to go, David!
Previous:From: David WheelerDate: 2003-05-30 18:30:59
Subject: Re: Way to go, David!

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group