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

151–160 of 199 posts

Re: You Don't Need UUID

#151

Post by hot_gril »

ekojs wrote: post #119

IMO, a good middleground is using schemes like TypeID[0], ulid[1], or KSUID[2] that provides a more compact and readable (base32) representation and provides better database locality (K-sortable). [0] https://github.com/jetpack-io/typeid [1] https://github.com/ulid/spec [2] https://github.com/segmentio/ksuid

As noted on an earlier HN submission about typeid, K-sortable only matters to distributed DBs, and things get tricky there. Spanner for example says to use deliberately unsorted primary keys.

I really think when you're picking PKs, you should simply use whatever the DBMS recommends for performance. It's not the PK's job to be typed, sequenced, human-readable, or anything like that; that can be handled by other cols and logging rules. Its job is to be fast in those joins you'll constantly be making against it.

Re: You Don't Need UUID

#152

Post by kiitos »

hot_gril wrote: post #31
nwah1 wrote: post #25

I recently found ULID. I like its simplicity. It is sequential. It has a very low probability of collision. And it is of a more reasonable length. Because it encodes the time, theoretically you could use it to grab the CreatedDate of a record without a need for another field. https://github.com/ulid/spec

Sequential isn't always simple. If your system is distributed in the slightest way (even just multiple threads), it's a bit of a luxury to find sequential guarantees.

ULIDs can get you rough ordering guarantees even in distributed systems. Precision, of course, requires synchronization, which is usually a non-starter.

Re: You Don't Need UUID

#153

Post by henvic »

sophiabits wrote: post #144
Supermancho wrote: post #129

Earlier quoted context omitted.

> 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/…

Also as a developer I really dislike UUIDs because the hyphens make it impossible to double-click copy. It’s a small gripe, but I need to copy IDs multiple times per day and it adds up. Other ID formats like cuid or KSUID don’t have hyphens in their canonical representation, and it makes them far more pleasant to work with

Yes! This might seem silly, but if you're working with a lot of data, it can be a pain and time drain...

Re: You Don't Need UUID

#154

Post by kiitos »

fuzzythinker wrote: post #124

I see ulid and nanoid being recommended here. I like cuid2 based on input from its README [0] and discussion [1] [0] https://github.com/paralleldrive/cuid2 [1] https://github.com/paralleldrive/cuid2/issues/7

cuid [0] seems to be a random letter, concatenated with a sha3 hash of:

- the system time

- a process-global singleton counter (incrementing with each ID)

- a "salt" derived from some number of bytes taken from an entropy source

- a "fingerprint" of some number of bytes taken from the same entropy source

this is an awful lot of work to be doing for each ID, to what end? well issue 7 [1] says that

> Cuid2 is good when you need something secure, extremely collision resistant, and your system is distributed or decentralized (e.g. you want to be able to create records with ids on the client side), or you are building software that may need to scale horizontally).

but I'm not sure how cuid as implemented provides a better answer in any of these dimensions to a plain old UUID

maybe I'm just being cynical, I dunno

[0] https://github.com/paralleldrive/cuid2/blob/fb07094487ba5ad0...

[1] https://github.com/paralleldrive/cuid2/issues/7

Re: You Don't Need UUID

#155

Post by imiric »

ekojs wrote: post #119

IMO, a good middleground is using schemes like TypeID[0], ulid[1], or KSUID[2] that provides a more compact and readable (base32) representation and provides better database locality (K-sortable). [0] https://github.com/jetpack-io/typeid [1] https://github.com/ulid/spec [2] https://github.com/segmentio/ksuid

I'm recently finding Cuid2 to be the best of these alternative GUIDs. They seem to have all of the benefits for what you would want to use a GUID for, but none of the drawbacks of existing implementations.[1]

[1]: https://github.com/paralleldrive/cuid2#comparisons

Re: You Don't Need UUID

#156

Post by hot_gril »

croes wrote: post #43
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? Nowadays many links are much longer because of referrer information and tracking parameters. So the UUID doesn't add much.

I noticed a recent change on YouTube where the "share" button now includes extra tracking stuff, making it longer than the actual URL in the address bar. Which is even funnier considering that they bought the youtu.be domain just to make shared URLs shorter.

Address bar: https://www.youtube.com/watch?v=SHWhKRKlG98

Share button: https://youtu.be/SHWhKRKlG98?si=gwQHHze3UnjTobJg

Re: You Don't Need UUID

#157

Post by eternityforest »

hot_gril wrote: post #145
traceroute66 wrote: post #107

Earlier quoted context omitted.

No. It's not irrelevant. As you have been told apple.com/iphone = www.amazon.com/dp/B09V3HZ8B5 The rest of what you posted on the Amazon link is tracking bullshit. Now, THAT is irrelevant !

Users aren't expected to manipulate URLs manually. If your URLs have extra stuff, that's what people are going to copy/paste into messages. Amazon product URLs are looong, but maybe people don't share them enough for Amazon to care. YouTube and Twitter put more effort into making them short.

I wonder if this is something Unicode could address. You could have something like quote marks that mean "Anything between these is data that shouldn't be seen in digital media but should be printed"

So you could have urls like:

example.com?&productname=somethinghumanreadable

Re: You Don't Need UUID

#158

Post by hot_gril »

eternityforest wrote: post #157
hot_gril wrote: post #145

Earlier quoted context omitted.

Users aren't expected to manipulate URLs manually. If your URLs have extra stuff, that's what people are going to copy/paste into messages. Amazon product URLs are looong, but maybe people don't share them enough for Amazon to care. YouTube and Twitter put more effort into making them short.

I wonder if this is something Unicode could address. You could have something like quote marks that mean "Anything between these is data that shouldn't be seen in digital media but should be printed" So you could have urls like: example.com? &productname=somethinghumanreadable

The browser would also have to understand not to copy that part by default. But HTTP disallows unicode chars in URLs. There could instead be some "sharable URL" web API, but it seems like a small enough problem that sites are content just providing a custom share button if needed.

Re: You Don't Need UUID

#159

Post by emodendroket »

sophiabits wrote: post #144
Supermancho wrote: post #129

Earlier quoted context omitted.

> 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/…

Also as a developer I really dislike UUIDs because the hyphens make it impossible to double-click copy. It’s a small gripe, but I need to copy IDs multiple times per day and it adds up. Other ID formats like cuid or KSUID don’t have hyphens in their canonical representation, and it makes them far more pleasant to work with

If that’s your issue passing the formatting option to your GUID library to get the dash-free solution seems like it would resolve it.

Re: You Don't Need UUID

#160

Post by rwiggum »

Nullabillity wrote: post #134
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…

There is no fundamental tech advance that caa make the birthday paradox irrelevant or obsolete, and there never will be.

all of cryptocurrency relies on sha256 the fact that the space is huge, and just ignores collisions. seems to work fine.
Post reply on HN