dennism@menace.rtech.COM (Dennis Moore (x2435, 1080-276) INGRES/teamwork) (08/15/89)
******************************************************************************* * Note -- every line of Dan's posting is below. Nothing is removed out of * * context. Every line of Dan's posting begins with a space then an asterisk. * ******************************************************************************* In article 3427, dlw@odi.com (Dan Weinreb) writes: *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. Actually, the above assertions, "[o]r if they do ..." and "[f]ew or none" are patently incorrect, and similar disinformation is appearing in this newsgroup with disturbing regularity. If you want to use this group as an advertisement, or as a forum to subvert the flow of FACT, then kindly turn to alt.flame or some other forum where those practices are accepted. I countered this assertion below in my original follow up posting. * * 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 By what metric is INDEX the largest US CASE company? Knowledgeware (IEW is the product) has more installed seats than any other CASE product. Pansophic is certainly larger than Index in revenues, as is Knowledgeware and Cadre for that matter. More uninformed disinformation, if you catch my drift ... *carefully considered the question and decided that existing DBMS *technology is inadequate for what they want to do. The major ECAD It couldn't have anything to do with a marketing or other business decision, could it? Your company wouldn't happen to be involved, would it (standard netnews behavior is to identify yourself and your company's relationship to the statement when said statement may be biased by your company's business). Once again, I work for RTI, which makes the INGRES database, and we have a joint development and marketing agreement with CADRE for their TEAMWORK CASE tool. *companies do not use any RDBMS for anything, or at least not for *anything at the heart of their systems. Is this a reason to justify OODB? Is this not, more reasonably, a reason *NOT TO BUY* Index? * *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? * No, I can't. I don't know the ECAD world. However, the reasons that many CASE companies that I have talked too (i.e. DEFT, CADRE, IDE, and KNOWLEDGEWARE, for instance (*I* like to justify my assertions)) did not use a commercial RDBMS in their products included: - none were available on all their strategic platforms when the product was originally written. - they didn't want a dependency on a third party. - they didn't want to offend customers who "religiously" :) preferred or abhorred certain products. - they had no in-house RDBMS expertise. - they did not want to pay (at the time, expensive!) royalties to the DBMS company. - they had no guarantees that the DBMS company would still be in business in a few years. - they sufferred from chronic (the layman's connotation -- i.e. "really severe") NIH (Not-Invented-Here) syndrome. - DBMS's didn't fit well on PC's at the time. *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? * YES, I can. Knowledgeware, the NUMBER ONE SELLING CASE tool in the world and in the US works this way. See above for my criteria for ranking CASE companies. *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. * Interesting statement, but generally "content free." Pretty easy to claim that performance would be "unacceptable" or that programming is "painful." *I* happen to *like* programming. If you read the POSTGRES PAPERS, by Stonebraker et al, you will see plenty of discussions on how RDBMS's are weak, and how they can become better. In the meantime, we have several hundred people here working on improving performance. Many are renowned experts in query optimization, caching and buffering, networks, etc. I'd like to hear why you think an OODB is inherently faster than any RDBMS, especially one so highly tuned. I firmly believe in "the right tool for the right job," but I don't believe that an OODB is a better tool for *ANY* job than a highly optimized OO *AND* RDBMS, which is what most major RDBMS's are becoming today. *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. * So what's your point? Does this not contradict your other assertions claiming that OODB's will be the basis of such systems? *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. * When will this happen? This is obviously not the state of OODB's now, but "in the view of the people in the DBMS companies" (if I may presume to speak for them), we do all the things I've talked about (the MS in DBMS), and we will also do those OO things, and we will outperform OODB's. I don't have any justification for the performance claim, although I would like to see benchmarks proving otherwise. I will also look for benchmarks justifying my claim. *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. * It's faster in an RDBMS, because of our caching and optimizations. If you want to always keep something in memory, you can do it in your software whether you use an RDBMS or nothing. If you want fast, multi-user response for data stored on disk, then an RDBMS gives better performance than OS buffering any day. It always may be possible to write a particular application better customized, but that will be true whether you use an OO or R/OO DBMS. *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". * Great. Assert and assert, but justification is out of the question, huh Dan? What problem *are* you trying to solve, Dan? Why don't RDBMS features "solve" these problems? For instance, you could store a CASE diagram as a BLOB in real-time, and fire off an asynch database procedure which invokes a method which does all kinds of stuff, including storing the thing in a normalized fashion (for reports etc.), and potentially invoking a compiler to create a new whole version, etc. Would this not be good enough? There will be a tradeoff between disk space and access and storage times, though, regardless of OO or R/OO. If you claim otherwise, I *DEMAND* justification of that assertion. *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 Oh yeah? Who? *system, and most realize that they aren't likely to get it from Oh yeah? What? *relational database technology. The leading technical people at these Oh yeah? Who? *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 Oh yeah? Who? Of course people are prototyping, but have any of them backed that up with announced release dates (other than INDEX, which I don't believe actually announced release dates, just the concept). *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 Oh yeah? Who? Did they say that an RDBMS with OO extensions can't satisfy their needs? BTW, INGRES and SYBASE have rules TODAY, and have had them for some time. (I believe ours are better, but what the hey.) *not be doing this if they saw the solution coming soon from the *relational companies. (The solution to the problem I'm talking about Oh yeah? Please read above about platforms and royalties and religions and ... *-- not to the ones that you're talking about, for which relational What are you talking about? You haven't countered a single point I've made. *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. * I recommend "The Postgres Papers" by Stonebraker and (Larry) Rowe (ed.), Memorandum No. UCB/ERL M86/85 from UCB. I am not sure how widely available this is, but if there is sufficient interest, I will find out how to get it. Larry Rowe is a frequent reader of/poster to this newsgroup (I DON'T SPEAK FOR LARRY, AND HAVE ONLY MET HIM ONCE). Basically, in summary, you may have a point on any [sic] of your issues. However, you don't back up your assertions with facts, and they are highly suspect (to me, at least) as a result. I think it is easy to imagine that RDBMS's can be extended with OO capabilities, and this is widely documented (as in TPP, above). If you have a valid criticism of PARTICULAR RDBMS's, feel free to criticize. If you think that RDBMS's are architecturally incapable of doing what your OODB will do, you are quite wrong, and you will soon see the folly of this point of view, as RDBMS's come out with the same OO features and capabilities, AND MORE. -- Dennis Moore, my own opinions, etc etc etc
rich@osc.COM (Richard Fetik) (08/16/89)
In article <3359@rtech.rtech.com> dennism@menace.UUCP (Dennis Moore (x2435, 1080-276) INGRES/teamwork) writes: <lots of interesting points in response to another posting> >Basically, in summary, you may have a point on any [sic] of your issues. >However, you don't back up your assertions with facts, and they are highly >suspect (to me, at least) as a result. I think it is easy to imagine that >RDBMS's can be extended with OO capabilities, and this is widely documented >(as in TPP, above). If you have a valid criticism of PARTICULAR RDBMS's, >feel free to criticize. If you think that RDBMS's are architecturally >incapable of doing what your OODB will do, you are quite wrong, and you will >soon see the folly of this point of view, as RDBMS's come out with the same OO >features and capabilities, AND MORE. > >-- Dennis Moore, my own opinions, etc etc etc Dennis, I don't have time now to touch on most of the issues you mentioned, but on the topic of extending rdbms to provide oo capabilities, please think about 1. the extra overhead as the oo model/paradigm must be converted by at least an additional layer of software if put on top of an rdb; 2. whether it is possible to extend the rdb sufficiently to provide a 'transparent' (non-obtrusive) persistent object environment; (sorry, 'BLOBS' are not objects.) 3. whether the oo model may have capabilities which just can not be faked by any stretching of the underlying relational software. It's true that I don't provide these answers here, but if, after thinking about the number of machine instructions executed for some arbitrary number of object fetches using both an extended rdbms and a true oodbms, you still don't see the performance advantage, I'll mail you lots of numbers/papers/etc. I haven't seen any claim that the rdbms companies would go out of business tomorrow (or next year), but I do have experience with UNIFY in a communications project a few years ago. After fighting slow performance, we pulled it out and replaced it with a primitive memory resident/flat file combination. My expectation is that a mature oodb product will be about 1/3 to 1/4 as fast as this type of design, while I know that UNIFY was about 1/100 times as fast. After some benchmarks get published early next year we'll see how the initial crop does in comparison to the rdbms's. BTW, I think I saw INDEX described as the largest CASE vendor in their press release when they announced the Ontologic deal. Were they desparate, or what?? Wouldn't they have gone for a relational dbms if they could've ?? instead of forking over so much money for an alpha test version from a very non-stable company ?? I will mail you stuff as soon as time permits; anyone else that wants to be put on the mailing list can also send me their name/info. There'll probably be too much to post, and most of it will not be of interest to most of the relational folks. -- rich@osc.osc.com 415-325-2300 uunet!lll-winken!pacbell!osc!rich