4 ms·
There are some nice features of using UUIDs rather than ints. It's been written about before, a few on the top of my head: Client side generation of ids. No ris
by cjblomqvist 3y ago
There are some nice features of using UUIDs rather than ints. It's been written about before, a few on the top of my head: Client side generation of ids. No risk of faulty joins (using the wrong ids to join 2 tables can never get any hits with UUIDs, it can with ints).
Those two sucks for us right now (planning to move to UUIDs).
- mdasen 3y ago> No risk of faulty joins Wouldn't Snowflake IDs also solve that problem? A Snowflake ID will fit within a signed 64-bit int. https://en.wikipedia.org/wiki/Snowflake_ID https://en.wikipedia.org/wiki/Snowflake_ID The nice thing about a Snowflake ID is that you can encode it into 11 characters in base 62. If I have a UUID, I'm going to need 22 characters. Maybe that doesn't really matter given that 11 characters isn't something someone will want to be typing anyway and Snowflake IDs do require a bit of extra caution to make sure you don't get collisions (since the number you can make per second is limited to how big your sequence generation is).
- j16sdiz 3y agothe same idea, but this is a IETF standard.
- dankebitte 3y agoUniqueness aside, UUIDs for public-facing IDs also prevent enumeration attacks and leaking business information other than timestamps.
- throwaway83623 3y agoThe "faulty joins" can be solved by having a shared sequence for all tables. A bigint column should be enough for most use cases.
- j16sdiz 3y agoshared sequence for all tables can't be parallelized