OO database concepts...

[Bill Kelly]

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

Maybe we need a way to combine double-entry bookkeeping,
relational databases, and table-oriented programming !


<grin>

SCNR,

Bill

 

[Austin Ziegler]

Maybe we need a way to combine double-entry bookkeeping,
relational databases, and table-oriented programming !

I understand the latter two quite well (well, SQL databases at least
, although I call the last "data-oriented" programming. I'm not
quite insane enough to understand double-entry bookkeeping

-austin

 

[samuel_x_winters_x]

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.

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