Re: [SQLObject] two postgres questions

[Bud P. B. <bu...@si...>]

On Mon, 02 Jun 2003 12:46:44 +0200
Magnus Lyckå <ma...@th...> wrote:

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

Agreed.  I tend to forget about pre-existing schemas since I decided
I don't have a need for this myself.


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

Well, I understand you philosophically, but what do you mean by object
identity?  Every instance in python has an OID which is basically it's
menory address...  ...and I don't believe anyone assigns OIDs in
python.  

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

Yes, I also see these two possibilities.  You haven't been explicit
about how this relates to GUID or other primary key, so I state is
more explicitly:

Tables that manage values (as opposed to objects) don't necessarily
need an OID as shadow information.  Your example is convincing; the
key of the dictionary is a good solution for a primary key.  

I'm not overly concerned with additional overhead introduced by a ORM
middleware layer, so I could probably live with an unnecessary GUID.
But thinking aloud, maybe there is some systematics to it since also
breakup tables used in many:many relationships don't need guids...
Hmmm.  just an intuition but I haven't understood the systematics of
it all the way...


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

I had a paper in mind that wasn't listed there, only on OIDs..  But
thanks for the links..

--b