I'm getting down votes, presumably because people think what I said is incorrect. Would anybody care to explain how UUIDs can have lower probability of collision than just random bits? (Apart from using a central coordinator for handing them out of course, which would defate the whole point.)
But version 1 of UUID's, for example, concatenates a MAC address, a timestamp, and a "uniquifying" clock sequence.
As long as you're ensuring your MAC addresses are all unique (which they should be, except for manufacturing error) and only one UUID library per device, collisions are impossible.
Whereas with random numbers, there's always a chance of collisions. (There are also other versions of UUID's that do include randomness, with collision potential, in exchange for not revealing information such as timestamps and MAC addresses.)
The rfc is rather long for a UUID being just a random integer...
But if we're talking about UUID v4, it seems that 122 out of 128 are indeed random. [1] So why not just go all the way? Who cares about these 6 bits of meta data?
But it isn't. A UUID is a disjoint-union of several different types of IDs, only one of which is just random bits, and if random bits is all you care about, then "random 128-bit number" is not only clearer but gives more entropy than "version 4 UUID".
That what I'm trying to ask, what is the purpose of this disjoint union, when would you ever use the "UUID-ness" of UUIDs (which is not the same as asking about the virtues of UUIDs of a particular version).
The virtue is, software has some idea what a UUID is. There's a mostly-random version which is also understood.
If you want to start doing your own thing, a random number is good. It's hard to get a good random number. I suggest starting with, hey you guessed it, the UUID library.
