Re: [SQLObject] two postgres questions

[Ian B. <ia...@co...>]

On Wed, 2003-05-28 at 18:53, Edmund Lian wrote:
> Apologies for the delay in replying...

No problem, we all have other lives too...

> > 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).

I think views don't jive well with SQLObject -- they create an opaque
structure.  But yes, normalization can lead to a whole bunch of tables. 
I'm interested extending the power of joins so that some of these can be
handled more easily, without having to have too many classes involved.

> 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.

Any ORM involves moving logic into Python (or whatever programming
language).  That's a compromise you'll have to deal with.

But you don't have to use complicated queries anyway.  There's nothing
intrinsically Wrong about doing the logic in Python.  List comprehension
even makes set operations look nicer, and caching can provide
performance improvements.

It could probably be argued that those complicated queries are a form of
premature optimization.  Like most optimization, complex queries usually
are based on the requirements of pieces of code that would otherwise be
considered factored.  Those queries may be an important form of
optimization, but I think that should still be accessible even if it
won't be as natural as using normal object access.

  Ian