[Pharo-project] relational database and id field

Schwab,Wilhelm K bschwab at anest.ufl.edu
Thu Apr 7 15:43:07 CEST 2011

That sounds like a one-to-many relationship.  In those cases, I create two tables, one for the singleton side and one for the many side.  The many side includes the key field(s) from the one side, and setting it/them establishes the relationship.  A unique ID field for the singleton side is helpful, especially if things get edited.  For many to many, I create a third table that does nothing but associate keys between the two tables - I'm not even sure if there is another way to do it??

From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Benoit St-Jean [bstjean at yahoo.com]
Sent: Thursday, April 07, 2011 8:57 AM
To: Alexandre Bergel
Cc: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] relational database and id field

One more remark,

Since you're storing objects into a RDBMS, I guess what you're trying to express into "the relational world" is a notion of pointer (such as an object contains a collection of something in one of its instance variable, or a child has a mother kinda relationship, link).  In that case, to save you headaches and lots of "weird object-oriented modeling", an oid (object id) is what is used normally.  Any sequence (the shorter the better, don't use GUID for instance!) would do...

Benoit St-Jean
Yahoo! Messenger: bstjean
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)

From: Alexandre Bergel <alexandre.bergel at me.com>
To: Benoit St-Jean <bstjean at yahoo.com>
Cc: Pharo-project at lists.gforge.inria.fr
Sent: Thu, April 7, 2011 9:49:11 AM
Subject: Re: [Pharo-project] relational database and id field

> Normally, you should always have a primary key to uniquely identify a record in a database table.  If you have an attribute (or a set of attributes) that can uniquely identify your ComicBook, you don't need an id field.  BUT, if you tell me you're going to store lots and lots and lots of those ComicBook instances, having an id (integer) as the primary key has potential non-negligeable advantages over, say, something like a name.  Mainly because an id (let's suppose it's an INT) takes way less storage than say a name (VARCHAR(30) for instance) and thus more index records can fit into the key buffer in memory.

Ok, I understand.

> 1) yes, always provide a primary key
> 2) if you have already A primary key (even a composite one)
>    2a) if you need performance and are gonna store LOTS of those objects, the smaller the key the better so you could create a surrogate key (the id key) instead of using the "real" primary key
>    2b) if performance is not an issue, you can use what is already available that uniquely identifies your object (row) in the database table


> P.S.  Are you using a particular OO-RDBMS framework?

No, I am correcting a student thesis :-)
I would probably not use SQL if I had to :-)


> -----------------
> Benoit St-Jean
> Yahoo! Messenger: bstjean
> A standpoint is an intellectual horizon of radius zero.
> (Albert Einstein)
> From: Alexandre Bergel <alexandre.bergel at me.com<mailto:alexandre.bergel at me.com>>
> To: Pharo Development <Pharo-project at lists.gforge.inria.fr<mailto:Pharo-project at lists.gforge.inria.fr>>
> Sent: Thu, April 7, 2011 9:19:03 AM
> Subject: [Pharo-project] relational database and id field
> Hi!
> Since there are some experts in databases here, I ask a general question about it.
> Assume that I have to use a relational database to store, let's stay instances of Stef's ComicBook class.
> Should the class ComicBook have a field id to uniquely identify a book?
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Alexandre Bergel  http://www.bergel.eu

More information about the Pharo-project mailing list