Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!uakari.primate.wisc.edu!csd4.csd.uwm.edu!cs.utexas.edu!uunet!odi!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.databases
Subject: Re: Recent discussions... (*long* controversial message)
Message-ID: <1989Sep5.214702.1377@odi.com>
Date: 5 Sep 89 21:47:02 GMT
References: <16753@pasteur.Berkeley.EDU>
Reply-To: dlw@odi.com
Organization: Object Design, Inc.
Lines: 95
In-reply-to: larry@postgres.uucp's message of 1 Sep 89 07:17:37 GMT

In article <16753@pasteur.Berkeley.EDU> larry@postgres.uucp (Larry Rowe) writes:

Thanks for your comments; I agree with most of what you say.

   2. OO -vs- R dbms wars

   of course, the "R" companies (rti, oracle (formerly relational software),
   informix (formerly relational database, inc?), etc.) will create OO versions
   of their programming languages too.  OO-3GL's and OO-4GL's.  and, i'm sure they
   will get forced to do C++ embeddings sometime too.  now, can they create
   seemless integrations.  depends on how hard they want to work at it.  
   personally, i think they can do it.  simple thought.  every implementation
   tactic used by "O" companies can be put into "R" company product.  the same
   primitives called by the language run-time system to the data storage system
   of the OO-C++ products can be implemented within the relational dbms.  not on
   top of, within.  several people mentioned that "R" products are putting in
   db procedures to win tp1 benchmarks.  currently those procedures are coded
   in a 3GL or 4GL.  but, they could just as easily call routines coded in
   the dbms implementation language (C) and they could access *any* internal 
   interfaces in the backend.  

Perhaps.  It sounds to me as if you're saying that the "R" companies
can build an OODBMS by essentially making a new product, except
sharing some internal pieces of the existing RDBMS product where
appropriate.  It's possible that this can be done.  I don't know much
about the internals of the ORACLE product or the RTI product.
However, I do understand the basic concepts of System R, and therefore
the basic concepts of DB/2, moderately well, and it seems to me that
any system that used significant amounts of that machinery would have
some significant technical disadvantages compared to our approach.  Of
course, maybe I'm just not being clever enough.  We'll see.

   the difference the OO-C++ products will have is the effort they put into the
   programming language runtime environment (object caching, smart pointer
   swizzling, locking, etc.).  

Yes, I think that's a big part of it.

			       (btw, dan and jack.  are you planning on
   supporting ad hoc queries in C++ that touch objects in the object cache and
   in the backend?  how many lines of code are you going to write in your 
   distributed query optimizer and executer? i'll bet you'll finesse this for
   now because it isn't crucial to your target market.  it will be if you want
   to get into the bigger MIS and end-user market.)  

I'll leave it to Jack to talk about queries; he'll be back next week.
But I strongly agree that the important issue is the distinction
between our initial target market versus the MIS, end-user market.
You're quite right that we are concentrating now on the needs of our
initial target market, and deferring issues that we think are mainly
of interest to the MIS and end-user market.

Earlier you commented on the difficulty of getting people to "switch",
by which I presume you meant "switch from relational to
object-oriented".  As we see it, our initial target market is
primarily not using DBMS's at all in the areas that we are hoping to
provide OODBMS's.  That is, they might be using relational DBMS's in
some areas, but there are other areas in which they are not using a
DBMS, and it is primarily those latter areas in which we feel our
product can be of the most value.  So, for the most part, we're not
trying to get people to switch, and we're not trying to compete with
relational databases head-on.  Object-oriented databases, at least for
the forseeable future, are mainly to fill new needs.

   one thing though.  relational products didn't really take off until ibm 
   blessed the technology by announcing db2.  i worry about the oodbms 
   technology because ibm doesn't have any internal project building prototype 
   products that they can pick up and productize. 

I feel that this would be an important issue for the MIS and end-user
market, but really doesn't matter in our initial target market areas.
Many of the major CAD companies used workstations, Unix, and C long
before IBM endorsed any of those things.  CAx people are not
influenced by IBM nearly as heavily as MIS people.

Regarding normalization in relational systems:

							the trick is to 
   precompute a main memory representation of the complex object and store
   that in the dbms along with the normalized version.

To be fair, though, there are some extra costs incurred by this trick.
You have to make sure that this precomputed representation is
recomputed (or cache-invalidated) whenever there's a change in any
value it depends on.  So someone has to check when those values are
changed; ideally there should be a trigger/integrity-like check, to
prevent slip-ups due to manual error, but even then the checks must
have some runtime cost.  There also must be some storage overhead cost
for storing two different representations of the same data.  It's
certainly a good trick and I'm sure it provides fine performance for
some applications, but in a speed-critical area with many updates, or
when the number of instances is very large, these costs would have to
be considered as part of a tradeoff.

Dan Weinreb		Object Design, Inc.		dlw@odi.com