Me and a few other developers at work were discussing GUID/UUIDs and why they are the ultimate primary key.  I love them!  Every new database I start, I use a GUID as the datatype for primary keys.  This frees me from the semantic key problem.  It also gives you the freedom to create the primary key from within your application, rather than making a call to the database to get the next primary key.  This gives you tremendous flexibility in disconnected apps, and increases your scalability in traditional apps.  Best thing since shoes without laces.

Marc Thevenin was convinced that there was no real way to guarantee a key based on a number could be created that would be truely unique.  I considered this a challenge and set out to prove him wrong.

Turns out, he's theoretically right, at least in the way GUIDs are generated.  Information provided at opengroup.org outlines the algorithm used to generate GUIDs.  If you look at it, it's based completely on two things.  The Time and a MAC address.  Many motherboards that have integrated network adapters, allow you to change the MAC address.  So, if you set two computers to have the same MAC address(of course, not on the same network segment), and power them on at the exact same time (or within 100 nanoseconds), the two computers could generate identical GUIDs.  Therefore it is possible in theory, but I suspect that the chances of this happening in reality is comparable to winning 5 different state lotteries on the same day.

Looking at the routine, I am amazed at the simplicity and robustness, but I do wonder about the following:

The time used to generate a GUID is the number of 100 nanosecond intervals that have occurred since Oct 15, 1582.  Near as I can tell between 1582 and 1990, over 128,502,443,520,000,000 intervals have passed that will never be used to generate GUIDs.  That's a waste of between 47-48 bits.  That means only 79-80 bits in the GUID are meaningful.