[Edmund Lian <elian@in...>]

Ian,

Apologies for the delay in replying...

You wrote:

> If you really need a sophisticated data definition, you can always
> create the table yourself, and allow the database to handle much of the
> logic (like constraints).  That seems acceptable to me.

Yes, this is a good solution.


> What I suspect Edmund's problem is, is that his tables don't map well to
> classes.  Or maybe more accurately, his *usage* doesn't map well to
> instances and attribute access.  I'm imagining that his applications are
> phrased with rows being relations, not so much structured data.  Or at
> least some of the data.

Not to mention that in a fully normalized database, there can be a ton 
of joins to get what you want (or else views are used, but it's the same 
thing).

My usage is certainly very traditional in that I use fully normalized 
data models. Getting what I want does require the use of subselects, 
multiway joins and outer joins, transactions and rollbacks, etc. I still 
can't see how to do these, or else change the data model to avoid these 
so that I can use SQLObject. But, I'll try and report back what I find.

...Edmund.