From: jrobie@netmbx.netmbx.de (Jonathan Robie)
Subject: Re: Object What is an OODBMS?
Organization: netmbx, Berlin, Germany
Date: Fri, 14 Aug 1992 15:09:10 GMT
Keywords: OODBMS, C++, POET

cy@genghis.borland.com (Cy Shuster) writes:

>[discusses limits of the relational model to store real world
>relationships, such as many-to-many]

>Have we really come full circle, back to Codasyl networked structures?
>What about the vaunted features of ad hoc queries and on-the-fly
>joins, over casting relations into concrete at schema design time?

Did you happen to see the POET tutorial that I posted?  We are
*not* a Codasyl database.  If you look at the examples the difference
is clear: in Codasyl you manipulate the database, in POET you simply
use C++ to manipulate your objects as you would in any other program,
and tell the database when you want objects to be stored.  You can
do ad hoc queries or step sequentially through objects of a given
type.  When you retrieve objects from the database they act just
like C++ objects.  Compare this to Codasyl, in which the program
must explicitly manage the relationships among objects in the
database.

We operate on a much higher semantic level than Codasyl, and in
fact on a higher semantic level than relational databases.  Although
you can place pointers or references in objects and follow them,
you do not worry about their database representation--when you store
or retrieve objects the database handles the conversion to and from
C++ pointers and references.  You are guaranteed that non-zero pointers
point to objects of the correct type, and we have referential integrity:
if a referenced object has been deleted, your pointer is set to 0.

Look at any book on SQL and you will see how complicated it is to
implement referential integrity or to represent hierarchy.  You will
also notice that the data structures are much more limited than a
normal programming language, and that representing objects is not
possible.  All this comes for free with POET.

Note that SQL has pointers too: every foreign key is simply a logical
pointer to a row in another table.  These references are typically
resolved by joins.  Many of these joins are needed only because you
can not represent the data as anything other than a two dimensional
table.  In particular, any join using a foreign key to combine tables
is an admission that you knew the structure you wanted but could not
represent it in the database--the join is no more flexible than a
direct logical pointer, just less efficient.

Your schema may be changed at any time, and we have object versioning.
Because the schema represents the objects in your C++ program it is
usually changed at compile time.  This is a limitation imposed by
the C++ language: our class dictionary can actually be manipulated
at run time.



Jonathan

=======================================================================

Jonathan Robie		jrobie@netmbx.UUCP
Arnold-Zweig-Str. 44	jrobie@netmbx.in-berlin.de
O-1100 Berlin		
Deutschland		Phone:  +37 (2) 472 04 19  (Home, East Berlin)
				+49 (30) 342 30 66 (Work, West Berlin)


-- 
Jonathan

===========================================================================