When are you truly forced to use UUID as part of the design?

Question

I don\'t really see the point of UUID. I know the probability of a collision is effectively nil, but effectively nil is not even close to impossible.

Answer 1

Everything has a non-zero chance of failure. I would concentrate on far more likely to occur problems (i.e. almost anything you can think of) than the collision of UUIDs

Answer 2

There is also a non-zero probability that every particle in your body will simultaneously tunnel through the chair you're sitting on and you will suddenly find yourself sitting on the floor.

Do you worry about that?

Answer 3

Aside from cases where you have to use someone else's API that demands a UUID, of course there's always another solution. But will those alternatives solve all the problems that UUIDs do? Will you end up adding more layers of hacks, each to solve a different problem, when you could have solved all of them at once?

Yes, it is theoretically possible for UUIDs to collide. As others have noted, it's ridiculously unlikely to the point that it's just not worth considering. It's never happened to date and most likely never will. Forget about it.

The most "obvious" way to avoid collisions is to let a single server generate unique IDs on every insert, which obviously creates serious performance problems and doesn't solve the offline generation problem at all. Oops.

The other "obvious" solution is a central authority that hands out blocks of unique numbers in advance, which is essentially what UUID V1 does by using the MAC address of the generating machine (via the IEEE OUI). But duplicate MAC addresses do happen because every central authority screws up eventually, so in practice this is far more likely than a UUID V4 collision. Oops.

The best argument against using UUIDs is that they're "too big", but a (significantly) smaller scheme will inevitably fail to solve the most interesting problems; UUIDs' size is an inherent side effect of their usefulness at solving those very problems.

It's possible your problem isn't big enough to need what UUIDs offer, and in that case, feel free to use something else. But if your problem grows unexpectedly (and most do), you'll end up switching later--and kick yourself for not using them in the first place. Why design for failure when it's just as easy to design for success instead?

Answer 4

UUIDs embody all of the bad coding practices associated with global variables, only worse, since they are superglobal variables which can be distributed over different pieces of kit.

Recently hit such an issue with the replacement of a printer with an exact replacement model, and found that none of the client software would work.

Answer 5

Using the version 1 algorithm it seems that it is impossible collision under the constraint that less than 10 UUIDs per millisecond are generated from the same MAC address

Conceptually, the original (version 1) generation scheme for UUIDs was to concatenate the UUID version with the MAC address of the computer that is generating the UUID, and with the number of 100-nanosecond intervals since the adoption of the Gregorian calendar in the West. In practice, the actual algorithm is more complicated. This scheme has been criticized in that it is not sufficiently 'opaque'; it reveals both the identity of the computer that generated the UUID and the time at which it did so.

Someone correct me if I misinterpreted how it works

Answer 6

A classic example is when you are replicating between two databases.

DB(A) inserts a record with int ID 10 and at the same time DB(B) creates a a record with in ID 10. This is a collision.

With UUIDs this will not happen as they will not match. (almost certainly)