Re: OO database concepts...

On Mon, 28 Mar 2005 08:54:48 +0900, [e-mail]
<[e-mail]> wrote:
> "Austin Ziegler" <[e-mail] > wrote in message
>>> - Every class can have an extent and queries can start here
>> If I understand this ("extent" appears to mean something
>> different to the makers and unfortunate users of OO databases
>> than it does to the rest of the universe),
> Perhaps you have a different notion of "rest of the universe", but
> it is "extent" is certainly not a new concept, and entirely
> consistent in ODBs.

And as you've used it, it means something entirely different than it
does to the relational database world.

An extent in relational databases has nothing to do with the logical
structure of the database. It has everything to do with the physical
structure below the SQL layer -- it's something that *only* the
person who has to maintain the physical database layout need concern
himself with.

As I've said, "extent" appears to mean something entirely different
to users of object databases. Unfortunate, because it means that the
discussion becomes that much harder.

>> this is dependent upon the design of the database schema, whereas
>> with relational databases, this is inherent in the nature of the
>> database concept.
> Not true. If you have order_details as a table in an RDB your
> queries can start there. If you have OrderDetail as a class in an
> ODB, your queries can start there. Absolutely nothing advantageous
> inherent in either model.

Wrong. The advantage always goes to relational databases here,
because the access path is not constrained in any way *ever*. It's
always a problem when you design your data model to match your
object model, because I guarantee that your object model won't be
the right one for all applications, whereas a proper relational
model -- and I'll be the first to admit that a lot of people are
lazy and don't bother to understand what power the relational model
provides because it isn't covered well (if at all) in much of
computer science and is looked on with disdain by a lot of major OO
"leading lights", meaning that there's a lot of bad models out there
-- will be easily adaptable for pretty much any application you have
with it.

>> OQL can paper over this, to some degree, but it can't fix the
>> underlying problem that relational databases were invented to solve
>> because hierarchical databases *cannot* solve this.
> Very interesting claim. But an ODB is not a hierarchical database
> (assuming your definition of hierarchical database is reasonably
> standard).

Yes, they are hierarchical. If there's a root object, there's a
hierarchy. There might be additional entry points possible, but the
moment you have a root object, you have a hierarchy.

>>> - Queries are declarative
>> This is a meaningless statement. Please expand so that it has
>> meaning.
> Errr, I think you "it is a meaningless statement *to you*.
> 
> A query is declarative means that any logical expressions or paths
> used to express a query are NOT necessarily the same as the paths
> traversed to execute the query after the query is optimized.
> 
> This also means that there is *MORE* than one way to express the
> same query, including more than one logical path traversal. Just
> as with SQL. And contrary to your earlier claims.

In other words, object database vendors discovered that their
products were impossible to use and had to come up with a cheap SQL
knock-off without understanding the relational model in the least.

>>> - Query optimization exploits indices and object structure
>> Implementation detail, probably brought on because OODBs weren't
>> even remotely capable of competing against a proper RDBMS with a
>> good ORM.
> These are quite astonishing claims, and I don't see any real
> substance to back them up. A "proper RDBMS" certainly does use
> query optimization exploiting indices to gain performance and
> allow for different formulations of the same query to be all
> executed efficiently.

I'll be honest: I haven't played with an object database in several
years. Maybe the object database vendors have finally figured out
that they screwed up and implemented relational-like features. The
model for object databases is fundamentally wrong, however, and that
part won't change. You want support for that statement? Do a search
for "Fabian Pascal object databases." He doesn't have much good to
say about SQL database vendors, either, but he has absolutely
NOTHING good to say about the theoretical garbage that lies behind
object databases.

  http://www.dbazine.com/codd.shtml
  http://www.dbazine.com/pascal5.html
  http://www.dbdebunk.com/page/page/1835439.htm
  http://www.dbdebunk.com/page/page/1115004.htm
  http://www.dbdebunk.com/page/page/1147345.htm
  http://www.inconcept.com/JCM/December2003/pascal.htm
  http://www.dbdebunk.com/page/page/806631.htm
  http://www.dbdebunk.com/page/page/754911.htm

(The inconcept article is particularly good.)

Ultimately, my problem with OODBMS is that they *aren't* useful for
multiple applications accessing the same data in different
(sometimes contradictory ways), and my experience with data suggests
that no one is smart enough to get it right for all possible
applications of the data. SQL databases don't quite provide the full
power they should, but they're far better than anything remotely
hierarchical that requires graph navigation.

-austin
-- 
Austin Ziegler * [e-mail]
               * Alternate: [e-mail]