Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!odi!dlw From: dlw@odi.com (Dan Weinreb) Newsgroups: comp.databases Subject: Re: Extended RDB vs OODB Message-ID: <1989Aug11.143036.24703@odi.com> Date: 11 Aug 89 14:30:36 GMT References: <3560052@wdl1.UUCP> <408@odi.ODI.COM> <3324@rtech.rtech.com> Reply-To: dlw@odi.com Organization: Object Design, Inc. Lines: 130 In-reply-to: dennism@menace.rtech.COM's message of 9 Aug 89 17:13:28 GMT In article <3324@rtech.rtech.com> dennism@menace.rtech.COM (Dennis Moore (x2435, 1080-276) INGRES/teamwork) writes: |Many CAD and CASE applications currently don't use any existing DBMS, |relational or otherwise. Or if they do, they only use it at a high |level of granularity, or for peripheral functions. Few or none of |them use a relational DBMS to store, say, individual transistors, or |whatever are the small elements in which the program primarily deals. |Since they're not using a relational DBMS now, there's no issue of |"staying with an evolving rdb". This is common disinformation that OODB companies have been spreading in an attempt to generate a "need" for their product. If you intend to use comp.databases as a forum for insult and invective rather than information and discussion, I won't continue to reply to your postings. Most CASE companies use RELATIONAL databases at the hearts of their products. For instance, Cadre (teamwork) have used a number of commercial databases on different platforms, and are forging a MUCH CLOSER relationship with my company (RTI). IDE (Software through Pictures) uses an in-house RDBMS called TROLL, and are forging a MUCH CLOSER relationship with Sybase. I stand by my statement, above. The largest U.S. CASE company, Index Technologies, does not use any DBMS in its product. They have carefully considered the question and decided that existing DBMS technology is inadequate for what they want to do. The major ECAD companies do not use any RDBMS for anything, or at least not for anything at the heart of their systems. To explain what I mean by this, consider the following questions: Can you name one serious ECAD system in which each gate and each wire of a schematic is represented by one or more tuples in a relational database system? That runs simulations or design rule checks by accessing the relational database system for each circuit element? Can you name one serious CASE system in which each, say, box and connection of a dataflow diagram is represented by one or more tuples in a relational database system? That refreshes its video display by accessing a relational database for each of these little elements? This isn't generally done because (a) the performance would be unacceptable, and (b) the amount of programming needed to translate between the datatypes and computational constructs of a relational database and of a programming language would be too painful. Those CAD systems that are built on relational databases use them almost exclusively for selection, and sometimes for projection, but perform or precompute joins in the program memory of the design tools. Such tools read the appropriate chunk of the database at startup, and build internal record and pointer structures from it in virtual memory. Thus, a design session starts by copying one part of the disk into another. At the end of the session, the internal structures are converted back to tuples and written to the database. This loading and unloading can be very slow compared to the time to make small change in a design. Most CAD systems don't even work this way: they store their data in files, in the operating system's file system. Many databases have substantial object-oriented features; 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". We have presented our ideas to a range of leading CAD, CASE, and related companies. Many of them are very interested in seeing such a system, and most realize that they aren't likely to get it from relational database technology. The leading technical people at these companies are quite sophisticated about software technology; they can't be "fooled" by simplistic "disinformation". Being sophisticated, they are of course skeptical of all future claims until they see real working systems. But they also have a good understanding of what exists now, and why it works the way it does. In fact, several of these companies, who can't wait for the new OODBMS's and obviously can't be sure when those new system will appear, have been working on in-house solutions, usually very specialized OODBMS's (in the sense that I use the term) tailored for their own application. They realize that their in-house systems are stopgap measures, and hope to replace them with a more general, complete, tuned commercial OODBMS product at some point. They would not be doing this if they saw the solution coming soon from the relational companies. (The solution to the problem I'm talking about -- not to the ones that you're talking about, for which relational technology works OK.) Certainly many CAD/CASE systems will still need to communicate with relational database systems, since a lot of important data is and will be stored in RDBMS's. OODBMS's will not replace RDBMS's, and are not trying to. Rather, they are trying to answer new needs that will not be answered by RDBMS's. The mature, advanced CAD/CASE systems of the future will use both kinds of database system. For anyone interested in a deeper discussion of these points, I recommend a short paper called "Making Database Systems Fast Enough for CAD Applications", by David Maier. It's in an excellent anthology entitled "Object-Oriented Concepts, Databases, and Applications", edited by Won Kim and Frederick Lochovsky, ACM Press/Addison Wesley 1989, ISBN 0-201-14410-7. It's a new book and should be relatively easy to find.