M
Marian Edu
Guest
Yeah, that too but one should never look at them anyway... well, unless a perl warrior for which it might not be too complicate to decompile 
The reason I've mentioned only have to do with size (oh yes, sometimes it does matter), for a data warehouse implementation having guid as PK in dimension tables will not only increase the size of those tables but more important it will be multiplied in fact tables by the number of dimensions in a star schema. This will also be true for indexes both on dimension (parent) table and facts (children). While storage is chip nowadays this wasted space do affect performance by bloating memory with (slightly) larger keys and last but not least comparing two integers is much faster than comparing two strings of 36 characters And this has nothing to do with the order number thing, that is a natural key while we were talking about surrogates here... so it should not have any meaning, a sequence can work just fine and it does not matter if there are any gaps - having an auto-increment translates to a set to sequence next-value inside a trigger just easier to describe in definition. On 05/23/2014 08:46 PM, gus wrote: From: gus Post: RE: composite foreign keys Posted in: OpenEdge Development Link: http://community.progress.com/technicalusers/f/19/p/10162/39004.aspx#39004 so what. as long as the order numbers are unique, that could work. guids make my head hurt when i have to look at them. -- You were sent this email because you opted to receive email notifications when someone created a new thread. To unsubscribe from: - ...only this thread, disable notifications at http://community.progress.com/technicalusers/f/19/p/10162/39004.aspx#39004. - ...all email notifications from Progress Community, navigate to "Settings", click on the "Email" tab, then under the "Email Configuration" section, set Send Notifications to "No". -- m.edu keep it simple http://www.ganimede.ro http://ro.linkedin.com/in/marianedu medu@ganimede.ro mobile: +40 740 036 212 skype: marian.edu
Continue reading...
The reason I've mentioned only have to do with size (oh yes, sometimes it does matter), for a data warehouse implementation having guid as PK in dimension tables will not only increase the size of those tables but more important it will be multiplied in fact tables by the number of dimensions in a star schema. This will also be true for indexes both on dimension (parent) table and facts (children). While storage is chip nowadays this wasted space do affect performance by bloating memory with (slightly) larger keys and last but not least comparing two integers is much faster than comparing two strings of 36 characters And this has nothing to do with the order number thing, that is a natural key while we were talking about surrogates here... so it should not have any meaning, a sequence can work just fine and it does not matter if there are any gaps - having an auto-increment translates to a set to sequence next-value inside a trigger just easier to describe in definition. On 05/23/2014 08:46 PM, gus wrote: From: gus Post: RE: composite foreign keys Posted in: OpenEdge Development Link: http://community.progress.com/technicalusers/f/19/p/10162/39004.aspx#39004 so what. as long as the order numbers are unique, that could work. guids make my head hurt when i have to look at them. -- You were sent this email because you opted to receive email notifications when someone created a new thread. To unsubscribe from: - ...only this thread, disable notifications at http://community.progress.com/technicalusers/f/19/p/10162/39004.aspx#39004. - ...all email notifications from Progress Community, navigate to "Settings", click on the "Email" tab, then under the "Email Configuration" section, set Send Notifications to "No". -- m.edu keep it simple http://www.ganimede.ro http://ro.linkedin.com/in/marianedu medu@ganimede.ro mobile: +40 740 036 212 skype: marian.eduContinue reading...