davecb@yunexus.UUCP (David Collier-Brown) (08/18/89)
In article <1765@ethz.UUCP> marti@ethz.UUCP (Robert Marti) 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 such as | concurrency control, transactions, set-oriented data manipulation, | the ability to define views and to dynamically add new tables/columns, | etc. is | 1) faster than a relational system for typical technical/engineering | applications than a relational system, and | 2) not much slower than a relational system for traditional business | oriented applications. | How about some benchmarks, controversial as they may be? jack@odi.com (Jack Orenstein) writes: | Speaking for the system we're building at Object Design: The system is | based on C++. [...] | No benchmarks (yet), but a forthcoming posting addresses one aspect of | the performance issue for CAx applications. Well, many moons ago Drew Sullivan (drew@lethe) implemented a software engineering database while at Honeywell Corporate Confusing Sciences Centre, which probably fits the definition of an OODB... (In fact it was an entity-category-relationship database describing a set of objects and defining operations on them, which isn't actually an ODB, but can be called an OODB.) For operations with good locality of reference, it provided "as good" performance as a commercial RDBMS doing **exactly** the same thing. For operations which could be chararacterized as "for all possible objects of type X" it provided terrible performance. The production version of the system uses the said commercial RDBMS, purely to improve the speed of the "for all" processing. This is important for allowing real-time progress reporting. The development version of the systems still uses Drew's version because 1) it is dynamically configurable 2) it gives equal performence when doing the software-development tasks it was designed to do 3) it requires **far** fewer hours of the data administrator's time to keep happy, and 4) the group manager is resigned to running the report functions with "at 2300" and "nice -20". I'm biased, by the way. I wrote the data dictionary for it, based on the raw interface, back while it was still in development. It wasn't even slow then... --dave -- David Collier-Brown, | davecb@yunexus, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | Joyce C-B: CANADA. 223-8968 | He's so smart he's dumb.