Xref: utzoo comp.databases:7584 comp.lang.c++:10037 comp.object:1988 Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.databases,comp.lang.c++,comp.object Subject: Re: C++ and INGRES Message-ID: Date: 19 Oct 90 17:07:32 GMT References: <7797@star.cs.vu.nl> <813@orthogo.UUCP> Sender: davidm@cimshop.UUCP Distribution: comp Organization: Consilium Inc., Mountain View, California. Lines: 41 In-reply-to: basti@orthogo.UUCP's message of 18 Oct 90 09:07:46 GMT In article <813@orthogo.UUCP> basti@orthogo.UUCP (Sebastian Wangnick) writes: Well, we will use the Informix ESQL/C within our C++ project; some tests proved that the generated C code is acceptable to a C++ compiler. If it works this way, great. However, you might be happier in the long run by making all embedded SQL live in straight ANSI-C functions which are then called from your C++ code. This will probably make it easier to live with changes in the C++ compiler or the ESQL/C compiler or both. Of course, the main problem is how to integrate such a database into an object oriented framework. We have some ideas on that but these are still preliminary. Does anyone have come to a good classwork already? There are two approaches to this. One is to build your database interface on the idea that an entity in the database equates to an object on your interface. This will tend to be a very static way of looking at things and, therefore, your SQL interface will use static SQL in dealing with the database (which is a performance advantage). The problem will be dealing with strange queries, though (but maybe not much of a problem). For instance, when joining two entities, which "object" has control of the join (on which do you define it as a member function). The other approach is to build your database interface on the idea that a relational database is a form of object-oriented database. That is, build objects of the form Database, Table, View, Tuple, Attribute, etc. This will be a very dynamic approach using (potentially) a lot of dynamic SQL (thus it may have performance problems). However, it is also a very flexible approach that may allow you to do things simply that the first approach couldn't even touch (adding new tables or views should be child's play). The tradeoffs, though, are yours to decide on. -- ==================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"