Re: [SQLObject] two postgres questions

[Luke O. <lu...@me...>]

> But your observation (and Luke's) does raise a thought... perhaps there
> are three broad classes of database user:
>
> 1. Someone who wants an object store and isn't especially concerned
> about data integrity, flexibility, etc.
>
> 2. Someone who wants an object store but does want some measure of data
> integrity, has simple data models, and wants some ability to access the
> data via third party apps/tools.
>
> 3. Some who wants flexibility, ability to access the data via third
> party apps/tools, is concerned about data integrity, etc. Is willing
> trade pure object orientation for these.
>
> It seems to me that (1) is best served by ZODB, (2) is where the ORMs
> and SQLObject are, and (3) is where people like me are, but would prefer
> not to be.


Mostly agree with your taxonomy. I think it can be transitively restated as:

1. All data integrity / relational design in via object design. Database is
generic persistence.

2. Data design is via Relational concepts, but constraints and complexity are
still dealt with on the object side: they want to access their data models as
objects, but the data model is more important.

3. Recognizing that constraints are *part* of the data model, this is just a
clarification of (2), a desire to model everything via relational theory but
to access this model via objects.

I don't see anything inherent in (3) that requires you to "trade pure object
orientation", the problem is that we're not aware of an object mapper that
supports as much as we'd like.

...
>  But, none of these tools made it easy to do complex data models.

Since I'm interested in making SQLObject (or a byproduct of) able to support
what I consider to be all of relational theory in an object-accessible way,
I'm curious what you consider to be the too-complex parts today. So far I've
heard multi-way joins and constraints. Let me see if I can elaborate these,
then you do the same?

1. Multi-way joins, meaning n-way intersections. I've had to hack with
SQLObject to handle these in a reasonable way, but conceivable.

2. Multi-way joins, meaning join traversal. Seems to be supported, although not
necessarily efficiently. So I assume you mean (1)?

3. Date's Contraint taxonomy: Domain/type constraints, column constraints,
table constraints, and multi-table constraints (database constraints). I'll
probably expand on these wrt SQLObject soon, but wanted to put them all up
here for now.

4. Transition constraints (column, table, multi-table) are somewhat different,
and will almost certainly be messier. :)

- Luke