Comment by saagarjha
16 hours ago
Just use UUIDs as they were meant to be used, as a random identifier. Don't shove random other junk into it!
16 hours ago
Just use UUIDs as they were meant to be used, as a random identifier. Don't shove random other junk into it!
The point of shoving the timestamp into it is to make it work well with database indexes. UUIDv4 is awful in that regard.
Sounds like the problem here is that databases need to index on more than one thing at once
It doesn’t have anything to do with indexing more than one thing.
The issue with truly random IDs is that inserts are scattered throughout the B-tree index, which cause page splits, fragmentation, and poor cache locality. Using a timestamp prefix makes new IDs sequential, so inserts tend to land near the end of the index, which avoid all the B-tree trashing and improve write performance.
4 replies →
They already do. UUIDv7 neatly solves a common problem: a random, unguessable, public id that works well with databaes. UUIDv4 is infamous for this.
2 replies →