From: samuel_x_winters_x@...
Date: 2005-03-29T06:14:52+09:00
Subject: Re: OO database concepts...


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

And if that were the "rest of the universe", you earlier sweeping claim
about "extent" would be right.

> Wrong. The advantage always goes to relational databases here,
> because the access path is not constrained in any way *ever*.

This would be truly amazing. In every RDB I have ever worked with,
access paths available to my queries have been 100% constrained by what
keys and foreign keys are defined in the schema. No different than OQL
access paths being constrained by relationships in the ODL. Oops, I
repeat myself ...

> It's
> always a problem when you design your data model to match your
> object model,

With a narrow preconceived notion of
  object model = OOP view of one application logic
you would be right by definition. But that's an empty argument.

> lazy and don't bother to understand what power the relational model

Ummm. I'll resist :-)

> 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.

The fixed root object in an RDB is the rdb. The fixed root object in an
ODB is the odb. Both give you ways to start from there. Both allow you
to go from there to tables (rdb) or class extents (odb) or individual
objects (odb). Seems pretty clear to me, but it's fine if you don't see
it that way.

> > 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.

Your rephrasings are remarkable. You may note (otoh, maybe not) that
very similar things could be said about the transition from RDB to
(O)RDB.

I notice too that you did not refute my observation that your earlier
claims about multiple traversal paths for RDBs and not for ODBs were
incorrect. Or refute my observation about query optimization.

And while O(RDB)s are certainly an improvement over RDBs, there is a
lot of FUD around how well the objects are integrated. For example, the
query machinery and optimizer, the indexing, etc. really don't know how
to handle the object types declaratively or invisibly to the user. And
object-related queries in SQL3 have been shown to be very error prone,
even to experienced SQL people.

But, of course, it's fine if you don't see those aspects. I have my
biases too :-)

Sam