81–90 of 199 posts
Earlier quoted context omitted.
Plus I could easily represent UUID in base64, such as JlEt5BSYe0enwB7nxl5V6g, which makes it shorter if I need that.
Maybe use a smaller alphabet though, base64’s can be quite hard to read / spell out / reproduce as it includes confusing pairs. While somewhat less dense, base58 or rfc 4648 base32 mitigate these issues.
A UUID is 128 bits, or 16 bytes. This code suggests IDs which are 11 bytes. That's not really comparable. A UUID can also be encoded in any form, it doesn't need to be represented as the dashed string notation which is common, you can just as easily use the base58 alphabet suggested in the post. But the code in the post doesn't encode to base58 correctly. You need to map 58 bits of the input, sequentially, to one cha…
Since the alphabet is 58 characters, each character contains log2(58) bits. Since that's not an integer, the encoding process is a bit more complex than just mapping bits to characters in a table.
I think there's a better "You Don't Need UUID", which is that you probably aren't going to generate so many integers per second that you need to do so in a way that's perfectly collision free. For example, you can update a postgres integer 1000s of times per second, sequentially, and 100s of 1000s of times per second if you allow for gaps/ unordered sequencing. The reason to choose a UUID is because it doesn't requir…
Database "sequence" types that are used to create integer IDs often no not make any guarantees about being gap-free. This can be a problem for people who don't realize this, and use them for something that is legally required to be gap-free, such as invoice numbers in some jurisdictions. Unguessability is a nice layer to have in your security strategy, especially if you're passing IDs to and from a web page, but if t…
Yep, the docs from Postgres are very clear that `serial` has gaps. But you can also just create a counter table and manually manage the sequence if you have strict serial requirements.
Of course, if you have serial requirements a UUID would already not be viable.
The crux of this argument seems to be that UUIDs are too long? Which I disagree with. I can't memorize them, no, and it would be cumbersome to try to say one aloud, but these aren't situations I've ever found myself in. Does it make the URL in the URL bar longer? Yeah, but does that matter?
>Does it make the URL in the URL bar longer? Yeah, but does that matter? Nowadays many links are much longer because of referrer information and tracking parameters. So the UUID doesn't add much.
Not that people will care. Once a URL is longer than a few words plus a code most users won't even look, even if they bother that far. You'll be in danger of starting to hit some browser/server/proxy limits though.
Not that I mind that sort of information being lost, I'm happy for the incessant tracking of everyone's everything these days needs to go to hell.
AKA I will make broad sweeping stupid headlines
Earlier quoted context omitted.
Plus I could easily represent UUID in base64, such as JlEt5BSYe0enwB7nxl5V6g, which makes it shorter if I need that.
Maybe use a smaller alphabet though, base64’s can be quite hard to read / spell out / reproduce as it includes confusing pairs. While somewhat less dense, base58 or rfc 4648 base32 mitigate these issues.
Don’t forget: UUIDs are not dash-separated strings. They’re integers. You can render them differently if those dashes are sucky.
Earlier quoted context omitted.
I think a better argument is that that the identifier needs to be unambiguous in cases where e.g. an ID needs to be communicated over the phone between an end user and a customer service rep. But that is easily solved with encodings like Base58 that exclude ambiguous characters.
Once you get over about 10 characters the chance that the user will skip or repeat a character or misread one goes up. Sometimes when I order parts for my car the site wants the VIN to verify that the parts are correct for that vehicle. I often have to make two or three attempts at entering it to get it right.
[0] https://bohwaz.net/archives/web/Bubble_Babble.html
[1] https://iancoleman.io/bip39/
[2] https://web.archive.org/web/20090918202746/http://tothink.co...
Databases and lots of other things also have native support for them which makes them even more appealing to use.
Of course, there are plenty of reasons to avoid them like the article discusses. I'd almost certainly not criticize someone for choosing smaller IDs as long as security isn't an issue.