Xref: utzoo comp.object:3348 comp.lang.smalltalk:2907 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!sdd.hp.com!cs.utexas.edu!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.object,comp.lang.smalltalk Subject: Re: Objects versus SQL Message-ID: Date: 24 Apr 91 17:40:56 GMT References: <2272@media03.UUCP> Sender: davidm@cimshop.UUCP Distribution: comp Organization: Consilium Inc., Mountain View, California Lines: 43 In-reply-to: pkr@media03.UUCP's message of 23 Apr 91 08:57:17 GMT >>>>> On 23 Apr 91 08:57:17 GMT, pkr@media03.UUCP (Peter Kriens) said: Peter> Objects vs SQL Peter> Ok, this works. But now the second kind of table. This should link the Peter> objects. For example I have a Client record and each client can follow Peter> many classes (school!) and each class is attended by many pupils. Peter> (n:m). In Smalltalk this is very easy to express by using object Peter> pointers and collections. In SQL you can do it by having an extra table Peter> that has the Client id and the class. I haven't yet found an elegant Peter> solution to this problem yet. I do not want to hard code the semantics Peter> of a certain table into Smalltalk code. Peter> Basically, my question is: How do other people solve the clash between Peter> Smalltalk (or any object oriented language) and SQL? Most people take the simple way out of this and state that there is a *mandatory* 1:1 correspondence between tables and classes of objects. This means, though, that object pointers are generally not useful and that you have to code the semantics of each table into its corresponding object. Some might argue that this is a necessity as relational databases are merely the implementation of a data model and have no data-specific behavioral semantics whereas an object database include both a data model and behavior of that data. What you might consider is how to define joins and foreign keys in your object model. Many relational databases allow for the specification of foreign keys (therefore, the information is in the data dictionary) and an object system might look at these as object pointers. Careful, though, you are really running into the difference between object databases and relational databases. Eventually, you could be at the point where you've either implemented a relational database system in an object oriented language or limited the expression of either the relational tables (to conform to object specs) or the objects (to allow for data valued joins) or both. -- ==================================================================== 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!"