And one more remark about ids.� I prefer not to use domain related ids like ISBN, because some day those rules will change and become obsolet, and your whole schema will need to be changed :/.�
Using autogenerated ids are more confortable if you take that into account.
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@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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Benoit St-Jean [bstjean@yahoo.com]
Sent: Thursday, April 07, 2011 8:57 AM
To: Alexandre Bergel
> From: Alexandre Bergel <alexandre.bergel@me.com<mailto:alexandre.bergel@me.com>>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@me.com>
To: Benoit St-Jean <bstjean@yahoo.com>
Cc: Pharo-project@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)
>
>
> To: Pharo Development <Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.