Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!news.kei.com!world!kinsella
From: kinsella@world.std.com (Joe P Kinsella)
Subject: Re: Persistent objects in RDBMS
Message-ID: <CwFJ84.FK2@world.std.com>
Organization: The World Public Access UNIX, Brookline, MA
References: <35b7om$9s7@panix.com> <35cmhc$rc@ams.amsinc.com>
Date: Tue, 20 Sep 1994 13:09:40 GMT
Lines: 33

From my quick tour of DataLens, I don't see where it has much to do with 
persistent objects at all.  If you choose a relational database as a 
persistent store for your objects, you must not make the mistake of 
constraining your database schema or you object model by the limitations, 
nuances and/or weaknesses of either model.  ParcPlace of course constrains 
both, reducing their product to little more than nice a prototyping tool.

The first requirement of a relational access layer is to support a 
rich set of mappings between objects and tables.  These mappings can be as 
simple as attributes of objects mapping to columns of a table, a class mapping 
across multiple tables, or a gen/spec hierarchy collapsed into a single 
table or distributed across multiple tables.  The richer these mappings 
the better you can maintain the purity of both your table and object 
models, and the more successful you will be using an RDBMS as a 
persistent object store.

But there are a variety of other issues that need to be addressed if we 
choose to "wrap" our relational data as objects.  Replicating data as 
objects has two interesting affects.  First, objects have a longer 
lifespan than data.  And second, replicating objects at the 
application-level moves them further from their persistent store, leaving 
potential integrity issues that must be addressed.

So using an RDBMS as a store for objects is very much an achievable goal.  
But it requires supporting a rich set of mappings and addressing the 
numerous issues that arise from this architecture (object integrity, 
performance, object partitioning, concurrency management, typelessness, object 
identity, object interface, object DML, support for complex objects, 
support for heterogeneous objects, etc...).

DataLens, of course, pretends these issues so not exist.

							Joe Kinsella
