By a dual key scenario, I am envisioning two different fields: 1 would be the GUID and the second would be the sequential integer identity.
Thanks Tom Schreck 972-361-9943 -----Original Message----- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 08, 2004 11:43 AM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] GUIDs as Primary/Foreign Keys This is exactly where UUIDs come in handy: you can replicate to other DBs, combine data and otherwise mix it up without worrying about local/relative uniqueness. Creating two keys seems unlikely to help to me... you'll just end up with a composite key when you cross systems in any case and lose your "local key". As for performance, I've never seen any marked performance decline, but then again the database I'm working with (well... the ones I create) tend to be fairly small. The simple answer is to try it - does the (possible) performance decrease outweigh the benefit? Don't assume that it won't until you set up a test case and see - you might be pleasantly surprised (after all, an index on a UUID column should be quite fast - perhaps even coming close to eliminating any inherent performance problems). Jim Davis > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Schreck, Tom > Sent: Wednesday, December 08, 2004 9:51 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] GUIDs as Primary/Foreign Keys > > I'm viewing this from the perspective of taking a set of data and moving > it > from one environment to the next (ie, from dev to staging or staging to > production, all within the same database type). In a previous job we used > integers as PK/FK and when we went to move data we had a mess on our hands > because there's no guarantee that the integer will be unique across > databases. We had to build routines for jockeying integers when promoting > data. No fun. > > I like integers because they are easy to work with, smaller, and faster. > I'm almost at the point of saying any record needs an identity integer > (for > work within a system) and a GUID (for work across systems). Does this > seem > like a crazy approach? I probably will not go this route because of all > the > additional maintenance that goes with it. But it's an interesting > thought. > > Thanks > > Tom Schreck > 972-361-9943 > > -----Original Message----- > From: Tony Weeg [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 08, 2004 8:39 AM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] GUIDs as Primary/Foreign Keys > > Dave, > > from what you know/read have you seen any performance notes on > using GUID's vs. Identity int's? > > tw > > > On Wed, 8 Dec 2004 09:35:38 -0500, Dave Watts <[EMAIL PROTECTED]> wrote: > > > GUIDs are hard to guess when someone is hacking a URL or form > > > field. They are random, for all intents and purposes. GUIDs > > > take a bit more storage as well, if that is an issue. > > > > In addition, GUIDs make replication easier. SQL Server identity columns > > don't travel too well. > > > > Dave Watts, CTO, Fig Leaf Software > > http://www.figleaf.com/ > > phone: 202-797-5496 > > fax: 202-797-5444 > > > > ---------------------------------------------------------- > > You are subscribed to cfcdev. To unsubscribe, send an email > > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > > in the message of the email. > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported > > by Mindtool, Corporation (www.mindtool.com). > > > > An archive of the CFCDev list is available at > [EMAIL PROTECTED] > > > > > -- > tony > > Tony Weeg > > macromedia certified coldfusion mx developer > email: tonyweeg [at] gmail [dot] com > blog: http://www.revolutionwebdesign.com/blog/ > cool tool: http://www.antiwrap.com > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > [EMAIL PROTECTED] > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at www.mail- > [EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at [EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at [EMAIL PROTECTED]
