>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.
You also can't guarantee the receiving database will support identities at all, or in the same manner. >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. If you are concerned about portability, I would use a GUID generated by the application (CF or whatever). Then, store the GUID in a char field. GUIDs are _supposed_ to be unique across all systems. M!ke ---------------------------------------------------------- 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]
