> UUID versions 1, 2, 3, 4, 5 are already outdated.
Interesting comment, since v4 is the only version that provides the maximal random bits and is recommended for use as a primary key for non-correlated rows in several distributed databases to counter hot-spotting and privacy issues.
Edit: Context links for reference, these recommend UUIDv4:
https://www.cockroachlabs.com/docs/stable/uuid
https://docs.cloud.google.com/spanner/docs/schema-design#uui...
Yeah, I thought it was a strange comment, too. v7 is great when you explicitly need monotonicity, but encoded timestamps can expose information about your system. v4 is still very valid.
loading story #47291583
Yeah v4 is the goto, and you only use something else if you have a very specific reason like needing rough ordering
Deterministic uuids is a very standard usecase
You're talking about the hash-based UUIDv3/v5? I haven't found examples of those being used, but I'm curious.
Using MD5 or 122 bits of a SHA1 hash seems questionable now that both algorithms have known collisions. Using 122 bits of a SHA2/3 seems pretty limited too. Maybe if you've got trusted inputs?
loading story #47292258
loading story #47289864
loading story #47289212
If you want 128 bits of randomness why not use 128 bits of randomness? A random UUID presupposes the random number has to fit in UUID format.
loading story #47287294
Have you considered using two uuids for more randomness
Really? Doesn’t v4 locally make the inserts into the B-Tree pretty messy? I was taught to use v7 because it allows writes to be a lot faster due to memory efficient paging by the kernel (something you lose with v4 because the page of a subsequent write is entirely random).
loading story #47286386
loading story #47287527
loading story #47286156
loading story #47286325
I believe current official guidance if you want a lot of random data is to use v8, the "user-defined" UUID. The use of v4 is strictly less flexible here.
loading story #47287304
[flagged]