Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You Don't Need UUID

henvic.dev

Post reply on HN
Print view View original

121–130 of 199 posts

Re: You Don't Need UUID

#121

Post by refulgentis »

emodendroket wrote: post #28
Alupis wrote: post #18

Earlier quoted context omitted.

> Does it make the URL in the URL bar longer? Yeah, but does that matter? No, it doesn't. If you're using a central system to generate id's (UUID's or other), then you are indeed missing a lot of the benefits of UUID's and might as well use some other ID scheme. The benefits of UUID are many systems can generate them, and your database can eventually accept them, all with a very high guarantee of uniqueness/no-collis…

That’s an excellent point; that can end up being a bottleneck across many systems.

What can?

Re: You Don't Need UUID

#122

Post by siva7 »

olalonde wrote: post #113
siva7 wrote: post #74

> A UUID alternative like a73ba12d-1d8b-2516-3aee-4b15e563a835 is just wasteful from an user’s perspective. The argumentation in this article is pretty poor from my experience. A UUID isn’t meant to be handled by the non-technical end user. The end user usually doesn’t and shouldn’t care about the URL. I can assure there are bigger architectural problems in your design if your user has to care about accessible intern…

Does this help see what's wrong with UUIDs in URLs? A GitHub issue URL in a parallel universe: https://github.com/a73ba12d-1d8b-2516-3aee-4b15e563a835/e16957bf-7d7f-41f1-97f4-98c93a6c3540/issues/4e4e9133-bcdb-45b9-8dfe-9e951846e3c6

I see bad url design for other reasons but nothing wrong with UUIDs, so no it doesn’t help me see the argument.

Re: You Don't Need UUID

#123

Post by henvic »

cbarrick wrote: post #82
kiitos wrote: post #33

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…

The base58 code in the post is wrong, but your version isn't right either. 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. https://digitalbazaar.github.io/base58-spec/#encode

Hi. I'm the author of the post here.

I agree lines 12-14 doesn't do a proper encoding, but that's not what I was after. Would you still say it's still wrong if you consider that my function is not really encoding the string per se, but using rand.Read to generate entropy for what I want to be the final output (random string with the base58 alphabet)?

Re: You Don't Need UUID

#125

Post by konschubert »

henvic wrote: post #91

Author here. I posted this because I've witnessed many systems in companies I've worked for where our end-users needed UUID to communicate with it (technical support, customer ID, etc.) in a way that makes communication harder. We could've used another shorter ID scheme, which would be fine. The good thing about UUID is that it's omnipresent. From what I've heard, it's this lengthy (2^32) because it was hard to guara…

Just use the first N characters of the UUID if you want a shorter version of the UUID.

And if you want to be really human friendly, use one of those silly name generators.

Re: You Don't Need UUID

#126

Post by hot_gril »

AdamH12113 wrote: post #78
iaaan wrote: post #3

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? I appreciate shorter URLs any time I copy and paste them, which always involves looking at them and sometimes involves scrolling to the end to remove tracking- and search-related fluff. 128 bits is an absurd amount for a unique ID within a single system. Even 48 bits is very, very large -- enough to provide a unique ID (MAC address) to every Et…

Basically, you want UUID's 122 bits (128 minus 6 wasted on variant + version) if you can't afford collisions. If you have some DB enforcing unique IDs at creation time, you can manage with a lot fewer bits if you want shorter URLs or something.

Re: You Don't Need UUID

#127

Post by henvic »

stock_toaster wrote: post #98
kiitos wrote: post #33

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…

pedantry: uuidv4 is only 122 bits of randomness. > 6 predetermined variant and version bits, leaving 122 bits for the randomly generated part > --wikipedia

Indeed. That's why I mentioned it's a 128-bit identifier format in the first line of the article, rather than 128-bit identifier. I probably spent 10min writing something to explain this, but then it wouldn't really be helpful so I removed it.

Re: You Don't Need UUID

#128

Post by konschubert »

afgrant wrote: post #66
dgb23 wrote: post #16

An issue that is not solved by either UUIDv4 or the proposed solution (random base58 strings) is indexing performance. Both of those solutions typically make it hard for a DB if you write new entries, assuming you have an index on the ID. In addition it might be more calming to actually be sure that a particular ID is not in use without doing a round-trip. Is it practical to pre-allocate empty entries and reserve a s…

Are there modern databases that can’t readily index on a 128-bit value?

If you use sequential ids, the IDs most in use are the higher ones. So your index is “hot at the top” and you can keep that part in memory.

This is only a problem with extremely big indexes.

Re: You Don't Need UUID

#129

Post by Supermancho »

emodendroket wrote: post #4

> A simple ID like 3c6n63N is more than enough to represent any product while keeping it readable and making communication easier. A UUID alternative like a73ba12d-1d8b-2516-3aee-4b15e563a835 is just wasteful from a user’s perspective. I would challenge the premise we appear to be starting from, that the average end user cares to be dealing with any random string of numbers and digits. GUIDs work well, they’re implem…

> that the average end user cares to be dealing with any random string of numbers and digits.

A developer, which I took to be "the user" for the purposes of this writeup, cares. My small concern is that the rand is insufficient to generate a unique enough string (just use a lib like snowflake to get overkill entropy), but I'm sick of having the format at all for inconsequential ids (eg https://www.uuidgenerator.net/).

Post reply on HN