If you get a chance you may want to read "Using uniqueidentifier Data" at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/acdata/ac_8_con_03_2uox.asp
It covers some of the topics discussed here. The last line is "Consider using the IDENTITY property when global uniqueness is not necessary, or when having a serially incrementing key is desirable."
UUID's came about as a handle for object tagging in data exchange. I remember many of the early CIM discussions and resolutions was about UUID. The transformation from a communication handle into a database key was a natural evolution. When I design DBs I try to avoid using UUID as a primary key because is not as efficient as identity keys. If a rowset or a viewset require a unique handle for communication, this a different design requirement.
Since a viewset is any query that has a join clause, allowing the database to be as efficient as possible supports the notion of using identity over UUID. For example if there are 2 tables in a DB where one table has a UUID as the primary key and the 2 second table has a foreign key to the primary key of the first, it means 2 tables would require long UUID columns. Not so efficient.
In a design that has a UUID requirement, a good technique is to use the UUID as a property of a rowset and not as primary key. This technique is more desirable whenever the UUID rowset will be used with viewsets.
Joseph
----------------------------------------------------------------------- http://www.switch-box.org/CFSQLTool/Download/
Switch_box MediaFirm, Inc. www.Switch-box.org Loveland, CO USA
----------------------------------------------------------
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]
