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

11–20 of 199 posts

Re: You Don't Need UUID

#11

Post by richbell »

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?

Yes. That's one of the author's arguments.

) 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 an user’s perspective.

Re: You Don't Need UUID

#12

Post by jackblemming »

Doesn’t UUID have mechanisms to prevent collisions even if you start two processes simultaneously with the same initial seed? There are human readable tweaks you can make to them that preserve all of the good properties without limiting the pool much though.

Re: You Don't Need UUID

#13

Post by czechdeveloper »

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…

Plus I could easily represent UUID in base64, such as JlEt5BSYe0enwB7nxl5V6g, which makes it shorter if I need that.

Re: You Don't Need UUID

#14

Post by hot_gril »

no_wizard wrote: post #8

Isn't auto generating UUIDs "fast enough" in most situations that its negligible? In particular databases (where UUIDs taking space was a big concern) they have largely switched to a packed binary format that makes the size of UUIDs over time a non issue for all practical purposes.

UUIDs are packed in DBs. But they tend to get misused as PKs. In common relational DBs, your PK for every table should probably be bigserial.

Re: You Don't Need UUID

#15

Post by swader999 »

There are so many nuances and edge cases not mentioned in the article. The author needs to do several projects in real life before making global pronouncements like this.

Re: You Don't Need UUID

#16

Post by dgb23 »

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 set of them?

Re: You Don't Need UUID

#17

Post by NBJack »

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?

Agreed. Decorative URL slugs have been successfully used by everything from blogs to Amazon itself for over a decade. If anything, that should be the focus here. Short URLs aren't much of a help, especially when short is relative on something like a mobile device.

Re: You Don't Need UUID

#18

Post by Alupis »

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?

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-collisions. Not to mention the other nice bits like non-sequential and non-enumerability.

Most modern databases have UUID/Binary types/functions to allow for more efficient storage/handling anyway.

Re: You Don't Need UUID

#19

Post by WirelessGigabit »

jackblemming wrote: post #12

Doesn’t UUID have mechanisms to prevent collisions even if you start two processes simultaneously with the same initial seed? There are human readable tweaks you can make to them that preserve all of the good properties without limiting the pool much though.

v4 is. v1 relied on the MAC address and the time.

https://devblogs.microsoft.com/oldnewthing/20040211-00/?p=40...

Re: You Don't Need UUID

#20

Post by drcongo »

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…

I read the article, scratched my head, pondered, came here to see if anyone else was confused, and I'm glad I did.
Post reply on HN