On Sat, 26 Mar 2005 03:34:49 +0900, gabriele renzi
<surrender_it / remove-yahoo.it> wrote:
>> 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.

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 * halostatue / gmail.com
               * Alternate: austin / halostatue.ca