OO database concepts...

[Hal Fulton]

I've been thinking about OO databases -- never having really
used such a beast. In fact, I am not sure that OOD even exist
in the sense that I would like.

Here's one thing I'm thinking about...

When one class inherits from another, we take it for granted
that they are "type compatible." Anywhere a Mammal can be
used, we can specify a Dog. (Insert standard discussion of
duck typing here.)

I'm thinking of the usual paradigm where a table is an ordered
sequence of fields. Neglecting the methods (which is another
issue entirely), we can think of the fields as instance vars.

But if a have a database table of Mammals... I can't store a
Dog in it. Hmm. I think I wish I could?

And don't get me started on singletons. Basically, the traditional
relational model assumes a fixed set of fields; but Ruby makes no
such assumption. Even objects of the same class may have different
attributes and methods.

Would it make sense to create a database that modeled Ruby's
paradigm more closely? Am I talking nonsense?


Thanks,
Hal

 

[Aredridel]

An ORDBMS like that would be very nice.

Postgresql has some features like that: each class gets its own table,
essentially, but its members show up in parent tables:

CREATE TABLE mammals (
legs integer not null default 2
);

CREATE TABLE dogs (
fur varchar(255) default 'Long and dirty',
) INHERITS mammals;

insert into dogs(legs, fur) values (4, 'Silky smooth');

select * from mammals;

# => 4

There's quirks (bugs, I'd say) with IDs and such, but it's workable in
some cases.

Ari

 

[Asfand Yar Qazi]

An ORDBMS like that would be very nice.

Postgresql has some features like that: each class gets its own table,
essentially, but its members show up in parent tables:

CREATE TABLE mammals (
legs integer not null default 2
);

CREATE TABLE dogs (
fur varchar(255) default 'Long and dirty',
) INHERITS mammals;

insert into dogs(legs, fur) values (4, 'Silky smooth');

select * from mammals;

# => 4

There's quirks (bugs, I'd say) with IDs and such, but it's workable in
some cases.

Ari

There are loads of OO databases for that bloody 'J' language - but
none for any scripting languages! Not even for Python! I find that
utterly surprising. E.g. http://www.garret.ru/~knizhnik/perst.html

Perhaps Ruby needs to be the innovator in this field, shipping a full
file storage based OODBMS system with the standard library in the
future?

 

[vruz]

Perhaps Ruby needs to be the innovator in this field, shipping a full

file storage based OODBMS system with the standard library in the
future?

There has been Aruna DB around for a while.
http://www.arunadb.org

Not sure how widely use it is, performance or quality of the codebase
ignored too.

It seems like it hasn't been actively developed lately. (but that may
be a good reason for someone to pick the project up if you happen to
like it)

If it's your current subject of research, maybe you can have a look at
it and tell us what you find.

cheers,
vruz

 

[gabriele renzi]

Asfand Yar Qazi ha scritto:

There are loads of OO databases for that bloody 'J' language - but none
for any scripting languages! Not even for Python! I find that utterly
surprising. E.g. http://www.garret.ru/~knizhnik/perst.html

In pythonland they have a concept of OODB wich includes "atop", "zodb"
and something else. It does not seem to fit with what ODMG says is an
OODB, anyway.

Perhaps Ruby needs to be the innovator in this field, shipping a full
file storage based OODBMS system with the standard library in the
future?

maybe just a binding to GOODS

 

[Avi Bryant]

I've been thinking about OO databases -- never having really
used such a beast. In fact, I am not sure that OOD even exist
in the sense that I would like.

Here's one thing I'm thinking about...

When one class inherits from another, we take it for granted
that they are "type compatible." Anywhere a Mammal can be
used, we can specify a Dog. (Insert standard discussion of
duck typing here.)

I'm thinking of the usual paradigm where a table is an ordered
sequence of fields. Neglecting the methods (which is another
issue entirely), we can think of the fields as instance vars.

But if a have a database table of Mammals... I can't store a
Dog in it. Hmm. I think I wish I could?

Hal, you're thinking too much in the relational model still. Real
OODBs don't have tables, they have graphs of objects, just like in
memory. They tend to use persistence by reachability, which means that
they have a defined root object, and any object that you can get to
from that root object - regardless of type - gets stored in the
database. The only "table" of Mammals would be if you hung an array of
them off of the root, and you could stick whatever you wanted in that
array. This means the database has to be strongly, dynamically typed:
each object record knows what its own class is, and thus which fields
it has.

Note that this makes it much harder for the database to do automatic
indexing the way RDBMS do. Depending on the OODB, you may well have to
take care of this yourself, making sure that you have appropriate data
structures so that you can access any object by traversing a minimum of
pointer references and using as few large objects as possible (it's
usually a good idea to use trees of some kind for lookup rather than
massive hashtables, for example).

Gabriele mentioned GOODS. That's a reasonable open source choice if
you want a large-scale networked OODB, although you have to be very
careful about performance because every object access goes over the
network. I've written client libraries for both Squeak and Python (on
contract) for this, and porting the same design to Ruby would be very
doable - although the lack of a real WeakReference implementation will
make performance suffer. If you're careful, you can achieve
cross-language data sharing with this (I've done simple demos of having
Java, Python, and Squeak all accessing the same object data).

The author of GOODS also has a simpler on-disk OODB called DyBase that
there are already Ruby bindings to, that you might want to take a look
at for smaller-scale projects.

If you have more questions about OODBs, my general advice is to find a
Smalltalker - for whatever reason, in the Smalltalk world they're still
the default industrial choice (often in the form of GemStone, but
that's an expensive package targeted at big business; some of the heavy
users are JP Morgan, Washington Mutual, and the OOCL container lines).

Cheers,
Avi

 

[Austin Ziegler]

There are loads of OO databases for that bloody 'J' language - but
none for any scripting languages! Not even for Python! I find that
utterly surprising. E.g. http://www.garret.ru/~knizhnik/perst.html

Perhaps Ruby needs to be the innovator in this field, shipping a full
file storage based OODBMS system with the standard library in the
future?

There's no such thing as a good OODBMS.

Period.

-austin

 

[Glenn Parker]

There's no such thing as a good OODBMS.

Period.

+1

 

[Austin Ziegler]

Hal, you're thinking too much in the relational model still. Real
OODBs don't have tables, they have graphs of objects, just like in
memory. They tend to use persistence by reachability, which means
that they have a defined root object, and any object that you can
get to from that root object - regardless of type - gets stored in
the database. The only "table" of Mammals would be if you hung an
array of them off of the root, and you could stick whatever you
wanted in that array. This means the database has to be strongly,
dynamically typed: each object record knows what its own class is,
and thus which fields it has.

Note that this makes it much harder for the database to do
automatic indexing the way RDBMS do. Depending on the OODB, you
may well have to take care of this yourself, making sure that you
have appropriate data structures so that you can access any object
by traversing a minimum of pointer references and using as few
large objects as possible (it's usually a good idea to use trees
of some kind for lookup rather than massive hashtables, for
example).

There are three fundamental problems with OODBMSs -- and they stem
from the theory of OODBMS, not just the implementation. Avi just
pointed out the first -- the indexing on OODBMSs utterly sucks,
which means that the performance has to come from your object model,
whereas an RDBMS or ORDBMS can have additional indexing applied or
derived from how the application uses the data. The performance for
an OODBMS will therefore suffer far quicker than the performance for
an (O)RDBMS; this is due to the second fundamental problem.

Avi also suggests the second, but it's not clearly stated as a
fundamental problem: persistence by reachability. This specifically
means that they are very Pythonic: there's only *ONE* way to get at
a particular set of data. In a traditional RDBMS, you can access
data from many directions. Consider the typical example of "owned"
data, an order and its itemised details (e.g., the items on the
order). In an OODBMS, the only way to determine how many Widgets you
sold last month is to either (1) traverse the object graph for all
orders last month and visit the order details or (2) store the data
in both details and elsewhere, doubling your data storage for that
information. In an (O)RDBMS, you can simply query the order details
table without having to visit the orders themselves. This makes your
data much more accessible, and usable for ways that may not have
been envisioned by the original architects or designers. An OODBMS
locks you into a particular object model to access the data, leading
directly to the third problem.

Portability. If you need to change the object model at all in an
object database, you have to go through a full-scale migration of
the entire data store. In an (O)RDBMS, you have only to go through a
migration (and sometimes not even that) only on the tables affected.
If you want to change your OODBMS implementation, it's infinitely
harder than the already difficult problem of migrating (O)RDBMS
implementations.

OODBs are crap -- and always will be.

-austin

 

[Doug Beaver]

On Sat, Mar 26, 2005 at 01:56:53AM +0900, Austin Ziegler wrote:

[ snip good summary of three fundmanetal problems of OODBMSs (hard to
index, rigid access paterns, poor portability) ]

OODBs are crap -- and always will be.

the nice thing is that if you want to enforce a type hierarchy or
support different numbers of columns for a given class of objects, an
object-relational mapping layer will give you 80% of what the OODBMS is
giving you, without all the OODBMS baggage. "dynamic" columns are
pretty easy to setup with a RDBMS, as long as you don't mind reading in
multiple rows in order to recreate an object, along with a cheap join
against a domain table holding the column definitions. with modern
databases, it ends up being pretty fast.

i think ORM is already a de facto third class of database (as weird as
that sounds at first glance), and the ORM domain of solutions are only
going to get better at caching, prediction, and performance. i've been
working with hibernate lately and am pretty impressed with all the
optimizations it can make, my hand-coded database layers almost matched
its performance, and took literally dozens of hours longer to implement.

doug

p.s. i think the OODBMS manifesto is a good read, if anyone wants to
learn the motivations that led to creating them in the first place.

http://www-2.cs.cmu.edu/People/clamen/OODBMS/Manifesto/htManifesto/Manifesto.html

 

[gabriele renzi]

Avi also suggests the second, but it's not clearly stated as a
fundamental problem: persistence by reachability. This specifically
means that they are very Pythonic: there's only *ONE* way to get at
a particular set of data. In a traditional RDBMS, you can access
data from many directions. Consider the typical example of "owned"
data, an order and its itemised details (e.g., the items on the
order). In an OODBMS, the only way to determine how many Widgets you
sold last month is to either (1) traverse the object graph for all
orders last month and visit the order details or (2) store the data
in both details and elsewhere, doubling your data storage for that
information. In an (O)RDBMS, you can simply query the order details
table without having to visit the orders themselves. This makes your
data much more accessible, and usable for ways that may not have
been envisioned by the original architects or designers. An OODBMS
locks you into a particular object model to access the data, leading
directly to the third problem.

I think there is a need to clarify (at least for me, since I'm dumb and
I generally don't understand things).
There is one kind of things going under the name of OODB wich seem to
meet your description, but there is another one, the one advocated from
ODMG wich seem to collide.
For example, the Object Query Language seem to allow the same kind of
access to objects that you could get via SQL.

Also I'm not sure I understand: once you have access to the root object,
if you want to have different views of the data could'nt you just create
an object wich actually is this view ?

 

[Glenn Parker]

There are three fundamental problems with OODBMSs

Maybe four. Austin mentions poor indexing, searching limited by
navigation, and resistance to change. I would throw in another issue
that may be more related to particular implementations, but so far I've
seen it in every OODBMS.

That problem is granularity of data access. With an OODBMS, the minimal
unit of access is the object. If your design needs large objects with
many fields, you get to load large objects all the time. With a RDBMS,
the unit of access is an arbitrary subset of columns in a row. The
impact of this difference on real-world performance can be orders of
magnitude, and there's little you can do other than redesign your system
from the ground up to make it more "compatible" with your particular
OODBMS's philosophy.

OODBs are crap -- and always will be.

Ah, how do you _really_ feel?

 

[Avi Bryant]

Avi also suggests the second, but it's not clearly stated as a
fundamental problem: persistence by reachability. This specifically
means that they are very Pythonic: there's only *ONE* way to get at
a particular set of data. In a traditional RDBMS, you can access
data from many directions. Consider the typical example of "owned"
data, an order and its itemised details (e.g., the items on the
order). In an OODBMS, the only way to determine how many Widgets you
sold last month is to either (1) traverse the object graph for all
orders last month and visit the order details or (2) store the data
in both details and elsewhere, doubling your data storage for that
information.

I'm not going to address all of your points right now, though if you
like I can write some when I have more time, as someone who has done
major projects with both OODMS and RDBMS, about why I don't think the
issues are as clearcut as you're making them out to be. However, the
statement above is simply wrong. It doesn't "double your data
storage", because OODBs reference objects internally by ID, not by
value. Even if (as would be common) the details are referenced both
from the order and from some index elsewhere, the detail objects
themselves are still only stored once. It's like claiming that there's
"double the data storage" in an RDBMS because one primary key appears
as a foreign key in multiple other tables.

Yes, the indices themselves take up room, but I have no idea why you
would count this room for an OODB and not for an RDB. Are RDB indices
somehow magic, and take up zero space? Your OODB will be using exactly
the same kinds of data structures - BTrees, ternary search trees, etc -
that a relational database would, giving it very similar performance
and space characteristics, it's just that these structures are directly
available as part of the object model for you to introspect and tune to
your own needs, rather than hidden away as an implementation detail.
Yes, that's a tradeoff, but I'm not convinced it's one with an obvious
right answer.

Avi

 

[Austin Ziegler]

I think there is a need to clarify (at least for me, since I'm
dumb and I generally don't understand things). There is one kind
of things going under the name of OODB wich seem to meet your
description, but there is another one, the one advocated from ODMG
wich seem to collide. For example, the Object Query Language seem
to allow the same kind of access to objects that you could get via
SQL.

Five minutes ago, I knew nothing about OQL. Now that I know the
barest amount about OQL, I'm aghast that the OODBMS community would
come up with this bastardized SQL-like language that completely
misses the point of using SQL or any other relational(-like)
language. OQL does nothing to help with the fundamental problems
presented -- object databases are optimized for a particular access
path. That is, if I have:

class Order
attr_accessor :details
...
end

class OrderDetails
...
end

Under a relational database[1], these would be separate tables, so
that I could logically do:

SELECT COUNT(*)
FROM order_details
WHERE widget_no = 12345;

Under an active (in-memory) object model, an object database, or a
hierarchical database[2], the only way that I can find how many
12345 widgets have been sold is to traverse *all* of my orders --
*UNLESS* I keep the information separate, but I have then lost at
least some of the encapsulation that makes this model so useful in
most object cases.

Objects are not the most important thing about an application. It's
the *data* involved that's the most important thing about the
application. Objects are often an efficient[3] way of representing
that data for manipulation, but they are certainly not the only nor
always the best way to do this.

A good ORM like Og or ActiveRecord can make a huge difference in the
usability of an RDBMS for programmers who choose not to understand
the relational model. I've written custom ORMs for applications, and
they're not hard to deal with when you understand both your object
model and your data model -- and understand that your data model has
to have primacy, because the object model is application-specific,
while the data model is business-specific (and may cross several
applications, including many you have not yet even dreamt of doing
for a given set of data).

All that said, I'm quite impressed with what was shown regarding
PostgresQL's INHERITS feature. This seems like an idea that really
should be considered; it doesn't *quite* fit with RDBMS and
relational theory, but it looks very practical and usable. It should
be possible to emulate on Oracle with views and INSTEAD OF triggers.

Also I'm not sure I understand: once you have access to the root
object, if you want to have different views of the data couldn't
you just create an object wich actually is this view ?

Um. Under an RDBMS, yes. Under an OODBMS, not really. Not without
duplicating data, which is evil.

-austin
[1] I tend to agree with the analysis, if not the stridency, of CJ
Date and Fabian Pascal. The SQL databases we have now are NOT
relational databases, but they are certainly usable and they are
orders of magnitude better for most problems than OO databases
or hierarchical databases will *ever* be. There are times
when a hierarchical database is appropriate; it's rare.
[2] An object database, really, is a specialised case of a
hierarchical database with a few features that make it nominally
possible to traverse the resulting object graph a bit more
freely.
[3] Efficient for the programmer more than the computer.

 

[Austin Ziegler]

Have you considered Views? Relational views are of limited use (in
some domains) due to their data modeling limitations and view
update problems. Views in an ODB are richer, and can help localize
schema evolution and data migration.

I think that you're looking at RDBMS from a while back. As I
understand it, both Oracle and SQL Server have solved the view
update problems, but in diffferent ways.

-austin

 

[samuel_x_winters_x]

Five minutes ago, I knew nothing about OQL. Now that I know the
barest amount about OQL, ...

Some relevant bits of OQL you seem to have overlooked are:
- Every class can have an extent and queries can start here
- Indices can be declared and automatically maintained
- Queries are declarative
- Query optimization exploits indices and object structure

So I'm having a hard time with the basis for some of your points. Could
you clarify which of the above items fall short?

Sam

 

[Austin Ziegler]

Some relevant bits of OQL you seem to have overlooked are:
- 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), this is dependent upon the design of the
database schema, whereas with relational databases, this is inherent
in the nature of the database concept. If one is going to go to the
effort of doing that much separation, then one is probably better
off with an RDBMS.

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.

- Indices can be declared and automatically maintained

Fair enough. The objects can be indexed. That doesn't change that
object traversal is restricted by the folks who first implement an
object database schema. Trust me: they're not bright enough to do it
right. Neither are the people who first implement a relational
schema for a program, but it's far easier to manage the relational
schema and adapt it for alternative uses than an object database.

- Queries are declarative

This is a meaningless statement. Please expand so that it has
meaning.

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

So I'm having a hard time with the basis for some of your points.
Could you clarify which of the above items fall short?

I maintain that OODBMS are essentially hierarchical database
systems and that the performance for them outside of the precise
hierarchy in which the schema were defined will be questionable, at
best, without importing some relational database concepts. OQL is a
cheap imitation of SQL (which is a cheap imitation of real
relational database concepts, at that). I would question the sanity
of anyone who stores critical business data in an OODBMS, as they
pretty much require that the original implementers be brilliant at
all times. I know that I'm not.

I'll point to something else that Avi said: "if one is careful," one
can use a particular object database (GOODS?) both cross-language
and cross-platform. Sorry, but without being careful, I can use
pretty much any relational database cross-language, and many of them
cross-platform. This strongly suggests perhaps the biggest problem
with OODBMS: vendor lock-in is much stronger under an object
database than it will ever be with SQL databases.

-austin

 

[Avi Bryant]

Fair enough. The objects can be indexed. That doesn't change that
object traversal is restricted by the folks who first implement an
object database schema. Trust me: they're not bright enough to do it
right. Neither are the people who first implement a relational
schema for a program, but it's far easier to manage the relational
schema and adapt it for alternative uses than an object database.

Austin, this seems to be the core of your point: that it's easier to
adapt a relational database to changing requirements than an object
database. You haven't presented any evidence for it, and I'd say that
in my personal experience precisely the opposite is true. Data
migrations have, in the applications I've built and maintained, been
less frequently needed and much less painful on OODBs than on
relational databases. If you have some rationale behind this
assertion, please present it, so that I can try to understand why your
belief or experience is so at odds with mine.

I'll point to something else that Avi said: "if one is careful," one
can use a particular object database (GOODS?) both cross-language
and cross-platform. Sorry, but without being careful, I can use
pretty much any relational database cross-language, and many of them
cross-platform. This strongly suggests perhaps the biggest problem
with OODBMS: vendor lock-in is much stronger under an object
database than it will ever be with SQL databases.

You're misquoting me - GOODS happens to be very easy to use cross
platform, without any particular care needed; certainly easier than any
of the major relational databases I know. However, you absolutely do
need care to use it cross-language, and that is a major and very real
point in favor of using a relational database. If you need to support
multiple applications written in different languages with the same
data, a relational database is almost certainly the right choice.
Ditto if you want to take advantage of existing reporting tools like
DataVision. Ditto if you have SQL-savvy users and want to provide them
with ad-hoc query access to the database. Ditto if, for some reason,
you fear that you will have to change database vendors midstream.
There are, in fact, lots of great reasons for using relational
databases, and based on the needs of an individual project I often
recommend them to my clients. It's also true, however, that of the
three major projects I'm working on at the moment, all three of them
are using object databases. Why? Because for these projects, we're
getting better performance, easier migration, and faster development
time with an OODB than we would with an RDB.

Avi

 

[samuel_x_winters_x]

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.

In an ODB the OrderDetail class has an extent, which is the set of all
OrderDetail instances. The OrderDetail class also defines its
relationships. Here is a bit of the object schema definition (also ODMG
standards based):

class OrderDetail (extent Order_Details key ... )
{ attribute string quantity;
relationship Product product inverse Product:rder_details
}

Your queries can start at the extent Order_Details, which is no
different from your cited example of SQL:
SELECT COUNT(*) FROM order_details

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.

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

Fair enough. The objects can be indexed.

All interesting collections of objects can be indexed, including (but
not limited in any way to) class extents. Also, fyi, ODB collection
types include sets, bags, list, array, and dictionary (map).

That doesn't change that
object traversal is restricted by the folks who first implement an
object database schema. Trust me: they're not bright enough to do it
right. Neither are the people who first implement a relational
schema for a program, but it's far easier to manage the relational
schema and adapt it for alternative uses than an object database.


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.

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 would question the sanity
of anyone who stores critical business data in an OODBMS, as they
pretty much require that the original implementers be brilliant at
all times. I know that I'm not.

Pretty strong statements.

If I can summarize your claims:
1. ODBs need more brilliant up-front definition than RDBs
2. ODBs don't perform like RDBs
3. ODBs are hierarchical
4. ODBs make data migration more difficult
5. ODBs make schema change more difficult
6. ODBs take an applications stovepipe view, RDBs are business view
7. ODBs are less cross-language than (SQL-based) RDBs

Certainly 7 is a valid point if your ODBs do not support some standard
like the ODMG (ODL + OQL). I have not seen any real evidence from you
about 1-6. Maybe you can help back these up?

Thanks.

 

[Austin Ziegler]

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.

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.

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.

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.

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