Object-Oriented databases Reaerch

"Lee Fesperman" <firstsql DeleteThis @ix.netcom.com> wrote in message
news:4065EB5C.5894@ix.netcom.com...
<...>
 > Relational querying allows you to retrieve any object directly, without
traversing a network.

Which can be a problem if you've broken encapsulation by directly updating
the underlying object data.

And how do you know which object to retrieve? I suspect you've got some
attributes which define the search criteria, and I also suspect those
attributes are stored as data in other objects, objects which the user has
most likely just referenced. That's my core discomfort with RDB (aside from
the object decomposition overhead)... each and every relationship is a
search.

 > Serializing a part of the 'network' is an object persistence strategy, not
a database.
 > Navigation is complex and inadequate if you are doing more than simple
object
 > persistence.

"Inadequate"? That has not been our experience. Business applications have
well defined object relationships. You "navigate" because it makes business
sense to do so, not because of a DB constraint. The application gets build
around these relationships; it's a strength of using an OODB. As for being
complex, try managing a non-trivial object model with a relational
backend... now that's complex. We've done both: the original version was
Smalltalk with an RDB (it's been running for almost ten years now), the new
version uses GemStone/S and we've found the object navigation more than
adequate and the complexity *much* easier to manage.

 > Objects in a relational system define domains. They are not struct
definitions; they are
 > fully 'active' and support inheritance, polymorphism and encapsulation.

I suspect the current OO <> RDB tools are better than what I had to work
with years ago, but I would hate to give up my active OODB.
--
Bob Nemec
Northwater Objects<!-- ~MESSAGE_AFTER~ -->

Bob Nemec wrote:

 > "Lee Fesperman" <firstsql.DeleteThis@ix.netcom.com> wrote in message
 > news:4065EB5C.5894@ix.netcom.com...
 > <...>
 >
  >>Relational querying allows you to retrieve any object directly, without
 >
 > traversing a network.
 >
 > Which can be a problem if you've broken encapsulation by directly updating
 > the underlying object data.
 >
 > And how do you know which object to retrieve? I suspect you've got some
 > attributes which define the search criteria, and I also suspect those
 > attributes are stored as data in other objects, objects which the user has
 > most likely just referenced. That's my core discomfort with RDB (aside from
 > the object decomposition overhead)... each and every relationship is a
 > search.
 >
 >
  >>Serializing a part of the 'network' is an object persistence strategy, not
 >
 > a database.
 >
  >>Navigation is complex and inadequate if you are doing more than simple
 >
 > object
 >
  >>persistence.
 >
 >
 > "Inadequate"? That has not been our experience. Business applications have
 > well defined object relationships. You "navigate" because it makes business
 > sense to do so, not because of a DB constraint. The application gets build
 > around these relationships; it's a strength of using an OODB. As for being
 > complex, try managing a non-trivial object model with a relational
 > backend... now that's complex. We've done both: the original version was
 > Smalltalk with an RDB (it's been running for almost ten years now), the new
 > version uses GemStone/S and we've found the object navigation more than
 > adequate and the complexity *much* easier to manage.
 >
 >
  >>Objects in a relational system define domains. They are not struct
 >
 > definitions; they are
 >
  >>fully 'active' and support inheritance, polymorphism and encapsulation.
 >
 >
 > I suspect the current OO <> RDB tools are better than what I had to work
 > with years ago, but I would hate to give up my active OODB.
 > --
 > Bob Nemec
 > Northwater Objects
 >
 >

Honest question, not flame bait.

I have a pretty good acquantiance with RDBMS's but little
to none of OODBMS's

Let's say you designed an order entry system with appropriate
obejcts (and derived classes) for different types of orders.

Let's say the system was optimized for the order-entry clerks.
(As it probably should have been.)

Now, let's say that the same system will be used by the
warehouse folks for various purposes. What they want to find
out is, e.g. how may orders are within 3 days of promised
ship date. Can I add this query so that it executes without
traversing the whole database? Without restructuring the
database?

I know how to do this with an RDBMS (add a B-TREE index, for example).
What is the equivalent in the OODB world?

For what it's worth, assume the Walmart database
(several Terabytes).

--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch<!-- ~MESSAGE_AFTER~ -->