Re: [SQLObject] two postgres questions

[Magnus <ma...@th...>]

At 12:09 2003-06-02 +0200, Bud P. Bruegger wrote:
>Magnus,
>
>I very much agree with your approach to primary keys.  This is why I
>suggested to use GUID or UUID in SQLObject some time ago and voted
>against the possibility to use multi-column primary (and foreign)
>keys.

On the other hand, I can understand the need to intergrate with
Legacy databases, so allowing multi-column keys could certainly
be useful for *that*.

Another issue to consider is that SQL tables are much more limited
than Python classes. If we have a class X with an attribute Y which
is a dict containing string => string, that can obviously not be a
column in table X, but on the other hand, we would not assign an object
identity in Python for each dict element.

The most straight forward solution seems for me to be a table

X_Y with columns x_id int, key varchar(...), value varchar(...).

Now, it seems I neet to either obscure X.Y as a pickle etc, or to
give each dict element an object identity. One makes the database
less clear and searchable, the other makes the db much heavier than
the pure Python implementation.

>I believe I was originally convinced of this by a paper by Scott
>Ambler--but I didn't find the refernece anymore..

Me too. They are in my wiki I think.
http://www.thinkware.se/cgi-bin/thinki.cgi/DatabaseDesign


--
Magnus Lycka (It's really Lyckå), ma...@th...
Thinkware AB, Sweden, www.thinkware.se
I code Python ~ The shortest path from thought to working program