For all people worrying about the size of a UUID when sent as a string in a game, why would this ever be a problem? If size of updates was really a problem, you would be using some sort of binary format and not sending strings, no?
Anyway, what I did in a project in the past when sending UUID ids in JSON was to base64 encode them so a UUID like 179cb862-a623-11e8-9eae-ef59cb81df07 would be sent as F5y4YqYjEeieru9Zy4HfBw. So 22 bytes instead of 32-36 if sent directly as a string
Well no, not all UUIDs are the same, UUID7 does offer locality of reference.
It’s pretty simple, use automatically incrementing database sequences unless you have to use client/distributed generation of identifiers (e.g. creating records when disconnected). For the UUID use case, UUID7 is a good choice.
FWIW, I use PUID, prefixed with a 36 base timestamp (Integer.to_string(36)). Optionally, you can further prefix with a type abbreviation (a la Stripe). To keep the timestamp short, I use the amount of seconds since a given epoch (eg, the date the company was created). You can then “decode” a given ID, and you’ll get an approximation on when the record was created (not all IDs end up in a DB). This can be used as a cheap validation step since the date must be after the epoch.
So something like: usr_wqa9v9WWcZidGFW
As you know, you can tweak the entropy settings when using PUID. Since the ID above is prefixed with a “seconds since epoch”, we essentially end up with a scenario where if we generate 10k IDs in one second, we have a 1-in-1 billion chance of collision – which has typically been good enough for me (but you could always increase it).