Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!odi!jack From: jack@odi.com (Jack Orenstein) Newsgroups: comp.databases Subject: Re: Extended RDB vs OODB Message-ID: <1989Aug17.143431.25055@odi.com> Date: 17 Aug 89 14:34:31 GMT References: <3560052@wdl1.UUCP> <408@odi.ODI.COM> <3324@rtech.rtech.com> <1989Aug11.143036.24703@odi.com> <1765@ethz.UUCP> Reply-To: jack@odi.com (Jack Orenstein) Organization: Object Design Inc., Burlington, MA Lines: 73 In article cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >>With respect to the ongoing debate concerning OODBs vs extended RDBs, >>I'd like to see proof (make that circumstatial evidence, if you prefer) >>that an OODB which supports traditional basic DBMS features [is] >> [better than a relational system] >> >The one flaw in this request is that proof of concept can't be provided if the >concept hasn't been defined. I agree with Jon Krueger in that there is too >much hand-waving in this discussion ("our system is better than yours") >without defining the problem that is trying to be met. Dan Weinreb and I have tried to define the concept in earlier postings. From Dan: > Unfortunately, the phase "object-oriented" is used to cover so many > different areas that it's hard to conduct a meaningful conversation > about what "object-oriented database" means. Certainly, you can store > strings representing SQL strings in a relational database. Certainly, > you can add "rule" and "trigger" features to a relational database > system. And these are useful, and people will use them. > > However, the introduction of these features still won't result in each > gate and each wire being represented as an element in the database > system. The really interesting data like gates and wires will still > have to be stored in files in a file system, just as they are now in > every real ECAD system. > > In the view of the people in the OODBMS companies, we will have > succeeded when there is no longer any need for a CAD/CASE company to > use the operating system's file system for anything at all, and when > the CAD/CASE tool can be written in a single, unified language, with > no translation between normalized relational tuples on the one hand, > and a programming language with its type system on the other hand. > And all this without performance degradation. > > A particular requirement is that fetching a data value out of the > database system must be as fast as fetching a component of a structure > (record) in the programming language. > > That's what I really mean by "object-oriented database system". A > relational system with extra added "object-oriented features" like > rules and triggers, while it has its uses, does not solve the problem > that we are trying to solve. Those "features" are beside the point; > beside our point, anyway. These problems cannot be solved by taking a > relational database system and adding some new "features". From me: > Based on [interviews with potential customers], we concluded that > there is a need for high performance for fine-grain manipulation of > small, persistent objects. >1. Relational DBs provide things necessary for a multi-user world >(concurrency control, security, etc.) that may or may not be needed in the >object oriented world (perhaps only a specific area [CAD/CASE]). > >2. Object DBs provide things necessary in a single-user world (extreme speed) >that may or may not be needed in the relational world. Thus the need for >cached objects. CAx applications need transactions and multi-user capabilities also, and we are building in these features. Yes, CAx needs extreme speed, but design projects are typically carried out by teams, and the multi-user issues are at least as important as in business applications. Jack Orenstein Object Design, Inc.