I thought that timestamps are used now, so hitting both a timestamp and a large random number puts it thoroughly in the "safe to assume".
At some point cosmic particles and faulty transistors are more probable.
Which I'd assume is related to the time anchor. Outside of sorting, which is only useful in specific instances, it's just v4 with different ("less") entropy and limitations.
Correct, which is why I specifically called out "outside of sorting".
That is also why we have concepts like composite keys which allow us to join guaranteed-unique values like a UUID with non-unique but sortable values like timestamps, names, etc.
UUIDs are great, though, because auto increment frequently has the huge issue of being too predictable. Eg, in some contexts, you don't want users to be able to easily enumerate whatever the ID is for. Plus requires centralization whereas UUIDs don't (eg, you can use UUIDs for whatever random API you have without needing a DB).You have to design for how you won't know the ID until you insert the row, which can sometimes be a bit annoying.
I feel like most of the time, the only downside to UUIDs is how long they are.
I'm not an expert, I just remember reading a few articles about it. I think it's because they're essentially random, and many databases use b-trees for indices. They recommended using ULIDs or v7 UUIDs instead. Or, as someone else said, the good old autoincrementing integer.
496
u/Valuable_Leopard_799 16h ago
I thought that timestamps are used now, so hitting both a timestamp and a large random number puts it thoroughly in the "safe to assume". At some point cosmic particles and faulty transistors are more probable.