From: itsme213 <itsme213@...>
Date: 2005-03-26T04:50:03+09:00
Subject: Re: OO database concepts...

"Austin Ziegler" <halostatue@gmail.com> wrote in message

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

Is that true with queries (both OO method and OQL-like queries)? Indexes are
duplicate data whose coherence is maintained by the dbms. OQL surely allows
that?

> In an (O)RDBMS, you can simply query the order details
> table without having to visit the orders themselves.

Is that different from querying the extent of the OrderDetails class?

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

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.

And then again, the tradeoff looks quite different if you really need more
duck typing. Views can be helpful here too, as they let you say

"let's look at X as though it were a Y"
   instead of only
"define X as a Y"

No silver bullet, I guess ...