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: 7 Nov 90 18:19:26 GMT References: <0B010001.xkabkz@bse.com> Sender: davidm@cimshop.UUCP Distribution: comp Organization: Consilium Inc., Mountain View, California. Lines: 42 In-reply-to: eberard@bse.com's message of 6 Nov 90 11:46:32 GMT In article <0B010001.xkabkz@bse.com> eberard@bse.com (Edward V. Berard) writes: 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 Can you elaborate on this? In particular: a. Is there really any more additional software here than would normally be present in interfacing a relational database to a procedural system? You might have trouble embedding SQL in an an object-oriented language, but this is mostly because vendors haven't come out with, say, SQL/C++ preprocessors and you can usually get around this (in many cases) by embedding the SQL in a standard function and then building a member function to call the standard function. b. Are you making a distinction here between most relational DBMS implementations and the *relational model*? In one way, the object-oriented model could be looked at as the synthesis of the informational, behavioural, and procedural models of an application. Everthing I've seen suggests that the relational model should be able to express the informational aspects of an application as well as the object-oriented model. Most implementations of relational DBMS's haven't yet progressed to the point, though, of representing all the basic data types that an object can contain. By the way, a personal query of mine is whether, in using a relational DBMS within an object-oriented effort, it makes better sense to represent the relational DBMS itself as an object (containing Relations, Tuples, Attributes, etc.) or make direct use of the relational DBMS and represent the entities and relationships as objects. Any ideas? -- ==================================================================== 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!"