Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.object Subject: Re: Object-Oriented COBOL? Message-ID: Date: 8 Nov 90 19:22:19 GMT References: <0B010001.xkabkz@bse.com> <13921@neptune.inf.ethz.ch> <678@dlogics.COM> Sender: davidm@cimshop.UUCP Distribution: comp Organization: Consilium Inc., Mountain View, California. Lines: 54 In-reply-to: dsa@dlogics.COM's message of 8 Nov 90 00:24:42 GMT In article <678@dlogics.COM> dsa@dlogics.COM (David Angulo) writes: In article <13921@neptune.inf.ethz.ch>, marti@mint.inf.ethz.ch (Robert Marti) writes: | In article <0B010001.xkabkz@bse.com> eberard@bse.com writes: | >Good luck, and welcome to the object-oriented vs. relational DBMS wars. | >While a relational DBMS can be used with an object-oriented software | >development effort, you will have to: | > a. write some additional software to interface with the relational | > DBMS, | > b. very likely corrupt your design to accommodate the | > relational DBMS | | This sounds like a shot from the hip. | | Do you have any evidence to substantiate your second claim? | Well, I have been doing exactly this (using a relational DBMS with an OOPL - viz. c++) for over a year and I happen to agree with Mr. Berard. I am also not going to give "evidence" but I will relate my experiences a little. The problems mainly arise from the fact that relationships are developed via SQL queries. So, if Class1 has a collection of Class2, those instances of Class2 must be obtained with a query like "find Class2 where owner=Class1_key". Everytime a new relationship is established or a specific result set is needed, one must establish a new method to perform that query. This gets to be burdensome. The way I understand what OODBMS's are, these relationships are inherent to the storage and are automatically restored when the object is retrieved (I forgot the buzz word - was it activated?) and vice-versa. Another problem is that SQL is available from anywhere (this is a somewhat lesser problem if you have good conscientious programmers) so access to the stored "objects" is not confined to your class methods. I, too, have been in exactly the same type of project for about a year and a half and am not sure that I agree with Ed Berard. The reason is that, no matter what type of database system you are working with, when implementing an object-oriented system on top of it, it will become an object-oriented database (the term OODB is vague enough to cover a lot of things). So, on the one hand I agree that you will be developing code to convert SQL output to classes of C++ objects and this may take a little work. On the other hand, if your information model is complete so that your objects and relations agree, then this extra work *should* be minimized to mere structure copying. It took me a long time to realize this, though, so my implementation here has had to wrestle with similar problems because we learned as we went. Looking back at it, the problems could have been reduced greatly by better OOA/D (especially if it was able to treat the RDBMS as an instance of the class of OODBMSs). -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"