Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!uupsi!bse.com!eberard From: eberard@bse.com (Edward V. Berard) Newsgroups: comp.object Subject: Re: Object-Oriented COBOL? Summary: eberard@bse.com's message of 6 Nov 90 11:46:32 GMT Keywords: relational versus object-oriented Message-ID: <0B010001.08x941@bse.com> Date: 9 Nov 90 13:04:05 GMT Reply-To: eberard@bse.com Organization: Berard Software Engineering, Inc. Lines: 84 X-Mailer: uAccess - Mac Release: 0.2.7 In article , cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: > > 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. I believe that if I have need of persistent objects, I should not have to do anything special. Specifically, I should be able to store, retrieve, and make queries against objects without making any special considerations as to the storage implementation scheme. For example, if I wish to store an object, I should not have to separately extract all of its components and store them. I should be able to say store this object (regardless of its complexity). Relational DBMS users would not be very happy if, in order to store a record, they had to extract all the fields of the record and store them separately. I should not have to care about the underlying implementation of an object. The additional software I am referring to is usually in one of two forms: 1. To store an entire object, the software engineer must write a series of statements which extract the necessary information from the object, and then place this information into the relational DBMS. The retrieval process is the reverse, i.e., extract the relevant information and re-constitute the object. 2. The system implementers choose to create an "object-oriented interface" to the relational DBMS, i.e., they make the relational DBMS appear to be an object-oriented DBMS. In formulating queries against an object, I have to make special considerations for relational DBMSs. In effect, since it is difficult to store operations/methods in a relational DBMS, I may have to formulate special queries (e.g., calculations) to search for/retrieve information on objects. > 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. In the future, anything is possible. Unfortunately, my clients need to store, query, and retrieve objects today. > 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? In my opinion, it is perfectly proper to view a persistent storage medium as an object. You might say that it represents a collection, one of whose characteristics is persistence. -- Ed ---------------------------------------------------------------------------- Edward V. Berard | Phone: (301) 353-9652 Berard Software Engineering, Inc. | FAX: (301) 353-9272 18620 Mateney Road | E-Mail: eberard@bse.com Germantown, Maryland 20874 | ----------------------------------------------------------------------------