Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!odi!indirect!jack From: jack@odi.com (Jack Orenstein) Newsgroups: comp.databases Subject: Re: Extended RDB vs OODB Summary: Born-again DBMSs won't cut the mustard Message-ID: <411@odi.ODI.COM> Date: 9 Aug 89 17:37:18 GMT References: <3560052@wdl1.UUCP> Sender: news@odi.com Lines: 44 In article <3560052@wdl1.UUCP>, mitchell@wdl1.UUCP (Jo Mitchell) writes: > > > For those of us who are interested in CAD/CAM, CASE applications ... > > After watching the oodb action and "extended" rdb action for awhile I'm > of the opinion that all the extended rdb's will eventually turn into an > oodb (at least at the conceptual level). > > Because of this it seems most application developers will decide to "convert" > via the route with the least slope - by staying with an evolving rdb... I assume that by "extended rdb" you mean a relational database system that permits instances of object classes to be stored in fields of tuples, instead of just numbers and strings. There are different kinds of application developers, and they will have different paths to (or around) DBMSs. An important question is what are these developers doing about persistent storage now? Some CAx application developers store data in DBMSs, using "long fields", in which they can dump and then retrieve byte strings that have to be interpreted in the application code. Retrieval based on the content of such fields is possible only to the extent that other int or string attributes store summary information. An extended relational DBMS can certainly be built on top of a long field facility, and it would be surprising if a number of relational DBMSs did not go this route, turning their relational systems into "born-again" OO DBMSs. This would probably be appealing to CAx developers who are currently using long fields. On the other hand, many CAD/CAM and CASE developers have bypassed relational DBMSs due to performance problems. Such people have built their own, or have built on top of file systems. Since these users are not using any DBMSs currently, I don't agree that the proposed conversion scenario applies to them. Many users who have gone this route are becoming aware that OO DBMSs will meet their requirements for expressiveness, integration with the host language and, maybe most importantly, performance. I don't think that such users will be convinced by a thin layer of paint on top of something they considered and rejected before. Jack Orenstein Object Design, Inc.