[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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Expert? Certainly not me :) The question I will be waiting to see debated is whether you should "fabricate" an ID field (probably a counter), use ISBN or similar number, or use a compound key. FWIW, I invariably regret any decision I make in these areas, because there are tradeoffs. Relational databases are very good at what they do, which is storing tabular data and (most importantly) getting it back later; they are also a pain about it :( ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alexandre Bergel [alexandre.bergel@me.com] Sent: Thursday, April 07, 2011 9:19 AM To: Pharo Development 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Expert? Certainly not me :) The question I will be waiting to see debated is whether you should "fabricate" an ID field (probably a counter), use ISBN or similar number, or use a compound key. FWIW, I invariably regret any decision I make in these areas, because there are tradeoffs. Relational databases are very good at what they do, which is storing tabular data and (most importantly) getting it back later; they are also a pain about it :(
Thanks Bill. I share your opinion. Alexandre
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alexandre Bergel [alexandre.bergel@me.com] Sent: Thursday, April 07, 2011 9:19 AM To: Pharo Development 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Thanks you all guys! You rock! Alexandre On 7 Apr 2011, at 08:25, Schwab,Wilhelm K wrote:
Expert? Certainly not me :) The question I will be waiting to see debated is whether you should "fabricate" an ID field (probably a counter), use ISBN or similar number, or use a compound key. FWIW, I invariably regret any decision I make in these areas, because there are tradeoffs. Relational databases are very good at what they do, which is storing tabular data and (most importantly) getting it back later; they are also a pain about it :(
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alexandre Bergel [alexandre.bergel@me.com] Sent: Thursday, April 07, 2011 9:19 AM To: Pharo Development 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Thu, Apr 7, 2011 at 3:19 PM, Alexandre Bergel <alexandre.bergel@me.com>wrote:
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?
I always put an id field. All cases without id I've encountered were always a pain. I don't have any argument against unique id. Laurent.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Thu, Apr 7, 2011 at 2:39 PM, laurent laffont <laurent.laffont@gmail.com>wrote:
On Thu, Apr 7, 2011 at 3:19 PM, Alexandre Bergel <alexandre.bergel@me.com>wrote:
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?
I always put an id field. All cases without id I've encountered were always a pain.
I don't have any argument against unique id.
And if you are thinking about ISBN: - ISBN "should" be unique. In reality they're not. Because we communicate with software that have bugs. People who enter ISBN have bugs too. And when you mashup datas you always get soon or later 2 different documents with same ISBN. - documents edited before 1972 and not reedited after don't have ISBN. Laurent.
Laurent.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Alexandre, 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. To be brief 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? ----------------- 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: Pharo Development <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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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@me.com> To: Pharo Development <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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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)
From: Alexandre Bergel <alexandre.bergel@me.com> To: Pharo Development <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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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 Cc: Pharo-project@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@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)
From: Alexandre Bergel <alexandre.bergel@me.com<mailto:alexandre.bergel@me.com>> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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 Cc: Pharo-project@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@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)
From: Alexandre Bergel <alexandre.bergel@me.com<mailto:
alexandre.bergel@me.com>>
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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. On Fri, Apr 8, 2011 at 3:43 PM, Richard Durr <richard.durr@googlemail.com>wrote:
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 Cc: Pharo-project@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@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)
From: Alexandre Bergel <alexandre.bergel@me.com<mailto:
alexandre.bergel@me.com>>
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Ok Alexandre On 8 Apr 2011, at 14:50, Guillermo Polito wrote:
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.
On Fri, Apr 8, 2011 at 3:43 PM, Richard Durr <richard.durr@googlemail.com> wrote: 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 Cc: Pharo-project@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@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)
From: Alexandre Bergel <alexandre.bergel@me.com<mailto:alexandre.bergel@me.com>> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 07.04.2011 15:19, Alexandre Bergel wrote:
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 IANAE, but my definitive answer would be... Maybe. :) Depends on what other tables are in the database, their relationship with the ComicBook table,which you intend to query often, what you intend to query them for, etc.
Cheers, Henry
participants (7)
-
Alexandre Bergel -
Benoit St-Jean -
Guillermo Polito -
Henrik Sperre Johansen -
laurent laffont -
Richard Durr -
Schwab,Wilhelm K