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: [email protected] [[email protected]] On Behalf Of Benoit St-Jean [[email protected]] Sent: Thursday, April 07, 2011 8:57 AM To: Alexandre Bergel Cc: [email protected] 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 <[email protected]> To: Benoit St-Jean <[email protected]> Cc: [email protected] 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 > <[email protected]<mailto:[email protected]>> > To: Pharo Development > <[email protected]<mailto:[email protected]>> > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
