Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!lll-winken!uunet!zephyr.ens.tek.com!tektronix!percy!m2xenix!servio!marcs
From: marcs@slc.com (Marc San Soucie)
Newsgroups: comp.object,comp.database
Subject: Re: Looking for explanation of OODB problem
Message-ID: <1991Jun11.191255.2474@slc.com>
Date: 11 Jun 91 19:12:55 GMT
References: <1991Jun6.194440.2879@apd.mentorg.com> <1991Jun10.070451.18516@chinet.chi.il.us>
Organization: Servio Corporation
Lines: 36

Dan Hartung writes (and quotes Codd):

> In his new 1990 book on the relational model, Codd devotes a chapter to
> rebuttal of "Claimed Alternatives to the Relational Model", including
> Entity-Relationship, Binary and Universal Relational, and Object-Oriented
> approaches.
>
> "Can the OO approach to database management support distribution independence?
> In other words, can application programs remain unchanged and correct when
> a database is converted from centralized to distributed and later when the
> data must be re-distributed?  What support does the OO approach provide for
> built-in and user-defined integrity constraints that are not embedded in
> the application program?"
>
> I believe his point, however obliquely made, is that OO does not, in his
> view, have the flexibility to successfully operate under different
> configurations without change, as a relational language would (must).
> The paragraph cited above is merely a specific instance of this: by
> having a grab-the-object-until-done approach, relational integrity
> would be virtually unenforceable.  Ironically, this is very much akin
> to the record-locking that is done in so many "relational" databases
> (really semi-relational) -- e.g. xbase.  The "EDIT" command is
> actually something like an EDIT object in this sense.

How are the stated objections affected when the "relational" integrity of the
objects and their connections is maintained by code which executes within the
database server itself - local to their storage, not to the client? The
so-called "grab-the-object-until-done" approach is not the only approach
available in OODB's. Codd seems to have overlooked GemStone, for instance,
where built-in and user-defined integrity constraints are embedded in the
database, not in the application programs. Did he fail to analyze this case?

    Marc San Soucie
    Servio Corporation
    Beaverton, Oregon
    marcs@slc.com