My company recently interviewed a potential ColdFusion developer. In the interview,  he mentioned somthing about using UUID’s as primary keys. This sounded fairly interesting to me because I personally don’t like the auto-incrementing most database systems have (our Oracle 10g at work reuses keys if you actually DELETE a row which makes debugging hectic) and implementing my own version of auto-incrementing seems a bit like a hack but at least it works well so far:

(SELECT NVL(MAX(MYID), 0)+1 FROM DBNAME.TABLENAME)

After doing some research, however, it seems that using a UUID/GUID is not the most favorable thing to use as a key. Primary keys, by definition, are indexed and when it makes comparisons on multiple objects (like when doing a JOIN) it greatly benefits the database system to have to compare 32 - 64 bit integers depending on the processor other than 32 bit string of random hexadecimal characters. One figure I’ve read is that integer comparison takes 1 cycle to be compared in the CPU, while it may take as many as 32 comparisons for the UUID/GUID, and this doesn’t count storage space as a concern.

It may make sense for your project to use a UUID/GUID as the primary key if your project is small enough and won’t demand the resources of a popular social networking application, but even then I would suggest having your programming environment generate the UUID/GUID because it will make your application much more scaleable and portable if you need to move to another server or database backend.

In my case, I’ll keep continuing to use my auto-incrementing integers while attempting to find creative uses for UUID’s. They seem like too much fun to not be using them.

Want to read more on ColdFusion’s UUID implementation and the difference between UUID’s and Microsoft’s GUID’s? Read this Adobe Knowledge Base article (link, adobe.com)!