4 ms·

It's not like the only two choices you have in the world are UUIDs and auto-incrementing sequential IDs. There are many better alternatives to UUID for the gen

It's not like the only two choices you have in the world are UUIDs and auto-incrementing sequential IDs. There are many better alternatives to UUID for the general case in which UUIDv4 is used, that provide some of the following advantages (based on the implementation): - Simpler spec and implementation - Easier to enforce compatibility across implementations (no ambiguity about letter case, order or hyphenation) - Smaller size and better readability - Lexicographically sortable based on time of generation - Deterministic uniqueness guarantee UUID is too much of a jack-of-all-trades-master-of-none. It originally defined many versions (which should have been called "formats") for flexibility, but nowadays only UUIDv4 (and less often UUIDv1) seem to be in use. UUIDv3 and UUIDv5 rely on the insecure MD5 and SHA-1, which, while it seems UUIDv2 and Nil UUIDs were rarely ever used. I hate it when developers are always reaching immediately for UUIDv4 while they almost always have a better choice for their case.

developer2 5y ago
Agreed, I don't understand why anyone reaches for uuid v4; it's the dumbest thing out there that sees regular use for no reason whatsoever. The number of developers who reach for uuid v4 is scary; I swear they don't understand what it contains, or care to think critically about their use case. The worst is reading about using uuid v4 for "offline client-side ID generation", such that any client can fixate object IDs that wind up in the server's database, and in fact are likely NOT unique if you have nefarious clients purposely generating duplicates client-side. There is also no reason to give up 6 reserved bits of a uuid v4's 128 bits (it's only 122 random bits + 6 bits of unnecessary version info). If you want random IDs, make your own. Simply generate 16 bytes of raw data; or combine two random 64-bit integers; or combine a timestamp prefix with random bytes at the end. Your needs probably don't warrant exactly 128 (well, 122 bits) that uuid v4 gives anyway, so you can customize to a specific number of bits. You can also use base62 (0-9, A-Z, a-z) or base64 instead of hexadecimal (0-9, A-F) to reduce the number of displayed characters (eg. in URLs), while omitting the stupid hyphens of a uuid too. tldr; uuid v4 shouldn't even exist, and certainly should not be used unless integrating with pre-existing systems.
- henvic 5y ago
  I'm the OP. Well, I've used UUID to generate ids on the client-side for a metrics system. Well, if someone submitted duplicated data, my server would ignore it. The context is critical to decide whether you can let clients generate an ID or not. In my case, the worst that could happen would be a Denial-of-Service attack if someone found a weakness in the UUID algorithm I relied upon.
Zababa 5y ago
> There are many better alternatives to UUID for the general case in which UUIDv4 is used, that provide some of the following advantages (based on the implementation): - Simpler spec and implementation - Easier to enforce compatibility across implementations (no ambiguity about letter case, order or hyphenation) - Smaller size and better readability - Lexicographically sortable based on time of generation - Deterministic uniqueness guarantee Could you name a few with their trade off or point me to some resources? I only know about UUIDs and auto-incrementing sequentail ID, but I would love to add a few tools to my toolbox.
- crubier 5y ago
  CUIDs are a good example that tick all these boxes
vlucas 5y ago
Your points are true, but UUID is built-in to most databases, and thus the most easy to use and rely upon everywhere (i.e. "id" uuid NOT NULL DEFAULT uuid_generate_v4()). That's why it gets the most use now, and will continue to do so in the future. PostgreSQL (and other RDBMS) also supports storing and indexing the data in UUIDs in a binary format. With binary, the space and speed concerns are greatly minimized, especially when comparing UUIDs to other randomly generated homegrown strings.

developer2 5y ago

Agreed, I don't understand why anyone reaches for uuid v4; it's the dumbest thing out there that sees regular use for no reason whatsoever. The number of developers who reach for uuid v4 is scary; I swear they don't understand what it contains, or care to think critically about their use case. The worst is reading about using uuid v4 for "offline client-side ID generation", such that any client can fixate object IDs that wind up in the server's database, and in fact are likely NOT unique if you have nefarious clients purposely generating duplicates client-side. There is also no reason to give up 6 reserved bits of a uuid v4's 128 bits (it's only 122 random bits + 6 bits of unnecessary version info). If you want random IDs, make your own. Simply generate 16 bytes of raw data; or combine two random 64-bit integers; or combine a timestamp prefix with random bytes at the end. Your needs probably don't warrant exactly 128 (well, 122 bits) that uuid v4 gives anyway, so you can customize to a specific number of bits. You can also use base62 (0-9, A-Z, a-z) or base64 instead of hexadecimal (0-9, A-F) to reduce the number of displayed characters (eg. in URLs), while omitting the stupid hyphens of a uuid too. tldr; uuid v4 shouldn't even exist, and certainly should not be used unless integrating with pre-existing systems.

henvic 5y ago
I'm the OP. Well, I've used UUID to generate ids on the client-side for a metrics system. Well, if someone submitted duplicated data, my server would ignore it. The context is critical to decide whether you can let clients generate an ID or not. In my case, the worst that could happen would be a Denial-of-Service attack if someone found a weakness in the UUID algorithm I relied upon.

Zababa 5y ago

> There are many better alternatives to UUID for the general case in which UUIDv4 is used, that provide some of the following advantages (based on the implementation): - Simpler spec and implementation - Easier to enforce compatibility across implementations (no ambiguity about letter case, order or hyphenation) - Smaller size and better readability - Lexicographically sortable based on time of generation - Deterministic uniqueness guarantee Could you name a few with their trade off or point me to some resources? I only know about UUIDs and auto-incrementing sequentail ID, but I would love to add a few tools to my toolbox.

crubier 5y ago
CUIDs are a good example that tick all these boxes

vlucas 5y ago

Your points are true, but UUID is built-in to most databases, and thus the most easy to use and rely upon everywhere (i.e. "id" uuid NOT NULL DEFAULT uuid_generate_v4()). That's why it gets the most use now, and will continue to do so in the future. PostgreSQL (and other RDBMS) also supports storing and indexing the data in UUIDs in a binary format. With binary, the space and speed concerns are greatly minimized, especially when comparing UUIDs to other randomly generated homegrown strings.