gisborne wrote:
Truly random UUIDs have essentially zero chance of a collision; that's the whole point of the exercise. If you have a really good source of random numbers, you should clearly just use random UUIDs and relax about half of the problems you have with distributed information.
The only sort of problem we have is that often don't actually have a good source of random values, and then we get into philosophical and technical debates about whether particular combinations of timestamps and whether you're standing on your left or your right foot counts as sufficiently random.
“Anyone who attempts to generate random numbers by deterministic means is, of course, living in a state of sin.” John von Neumann
A Type 4 UUID has 2^122 possible values, so assuming a "truly random" number generation, calling 2 has a 1 in 2^122 chance of generating the same value. For each additional number generated in a series the probability increases. Using Type 1 gives a zero chance of collision (providing the same machine is generating all the numbers) since it is time based.
Therefore with the choice between a miniscule chance and a zero chance of collision, that latter would seem the best especially if dealing with any kind of financial database. Why create a problem that doesn't need to exist?
Plus of course there may be cases where the time element of a Type 1 UUID is a useful factor in itself as a form of metadata for creation time of the record (especially if transported from one database to another, when of course it will be necessary to check that no collision exists from two seperate UUID generators coincidentally having created a UUID at _precisely_ the same time).
Of course there may be circumstances where having the time data cause some sort of data protection risk, in which case another option is needed - in which case one may want to revert to the serial integer primary key, which is where we came in...