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 <[email protected]> > 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 <[email protected]> > 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: [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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
