dennism@menace.rtech.COM (Dennis Moore (x2435, 1080-276) INGRES/teamwork) (08/11/89)
There are some very complicated queries that CASE tools generally need to do, which can be slow, regardless of whether an OODB or RDBMS is used, depending on the implementation. For instance, "get me all systems which reference this variable" can be a many-table join when coded in the simplest, most normalized, least RDBMS-efficient way. Another example is "save this object as a new version of this object," which can involve obtaining a new logical key (a bottleneck) and saving a new version of the object in a catalog (another bottleneck). There are efficient and inefficient ways to code this and other CASE-necessary functions. Another area of concern is generally that CASE models are highly volatile. For instance, the name (which is often a primary key) of an object may be changed many times; the same object may appear in multiple locations of the same or different models; objects are inserted, deleted, and resurrected; and many thousands of objects may be in the same "databases." I think many CASE vendors (our own partners [Cadre] included) tried to implement poorly-defined data models of their CASE dictionaries on top of poorly chosen RDBMS's with very little in-house knowledge of RDBMS techniques at some time in the past, and came up with (surprise!) a poorly performing system. In addition, CASE vendors tend to be proprietary-minded and suffer from a large dose of NIH syndrome, not to mention "we can do anything better than the big guys" disease. In our partnership, we have educated our counterparts, prototyped a better design, and convinced them that RDBMS's are the way to go. -- Dennis Moore, Manager, INGRES/teamwork CASE product development My own opinions blahhhhhhhhh