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 >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> >
