[Pharo-project] relational database and id field

Richard Durr richard.durr at googlemail.com
Fri Apr 8 20:43:17 CEST 2011


I recommend ids because without them, objects that are *equal* but not *
identicall* do not really fit into the db. ^^



On Thu, Apr 7, 2011 at 3:43 PM, Schwab,Wilhelm K <bschwab at anest.ufl.edu>wrote:

> 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
>
> Thanks!
>
> > 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 :-)
>
> Cheers,
> Alexandre
>
>
> >
> > -----------------
> > 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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110408/bd0f2398/attachment.htm>


More information about the Pharo-project mailing list