pkr@media03.UUCP (Peter Kriens) (04/23/91)
Objects vs SQL I have been working on a Smalltalk SQL interface. I found a working solution but I am not thrilled. It seems very hard to link those two worlds into one paradigm. The power of objects, cq havings direct links to other objects, seems hard to translate into the power of tuples where links are made symbolically. I found that there are at least two different kind of tables. One table is a direct representation of an object, containing rows that are a direct match for the instance variables. The other table links objects, and are represented in Smalltalk as pointers to objects (mostly collections). For the first table it is not very hard to find a good solution. I created a SQLTable object that links a class to a table. Because you can ask the instance variable names to a class and can access the variables through their respective index, it is possible to build a select statement for a certain object without having to specify special hard coded routines in that class. Any class is automatically converted into a select statement by the SQLTable class. To abstract this, I made a Record class which contain some service routines like fields which gives the names of the instance variables and values which gives the values in the same sequence as the previous fields. e.g. Record abstract class for database objects Client Order OrderLine SQLTable links Smalltalk objects to a table Client -> instance var info + values -> aSQLTable -> select statement <table name> aClient <- setting of values <<- <- table This seems to work and it is very easy to create new classes which are stored in the database. What I really like about this method is the 1:1 relationship instance variables : columns without having code which knows about the semantics of a certain table. This makes it very easy to write save and select routines. Ok, this works. But now the second kind of table. This should link the objects. For example I have a Client record and each client can follow many classes (school!) and each class is attended by many pupils. (n:m). In Smalltalk this is very easy to express by using object pointers and collections. In SQL you can do it by having an extra table that has the Client id and the class. I haven't yet found an elegant solution to this problem yet. I do not want to hard codie the semantics of a certain table into Smalltalk code. Basically, my question is: How do other people solve the clash between Smalltalk (or any object oriented language) and SQL? peter kriens pkr@media01.uucp
davidm@uunet.UU.NET (David S. Masterson) (04/25/91)
>>>>> 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!"