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

171–180 of 199 posts

Re: You Don't Need UUID

#171

Post by ozyschmozy »

henvic wrote: post #166
monero-xmr wrote: post #47

Earlier quoted context omitted.

The lack of humbleness and respect for devs who have came before you and solved all these problems is coming through strong. But I myself was that way 15 years ago. It takes a lot of hard lessons to realize everything new is old and we truly stand on the shoulders of 7000 giants all standing on each others’ shoulders.

Did you even read beyond the title? To say that because of this choice of title, I lack humbleness or respect for peers who came before me is despicable. My title is too presumptive. Yet, the reality for almost everyone who doesn't interface with other systems that already require UUID is that. The brief article gives some points – backed by trustworthy sources – and shows some alternatives without further ado. I did…

> Did you even read beyond the title?

Not the person you're replying to, but the end of the first paragraph in your article is

> and I want you to understand why you *certainly* don’t need it

(emphasis mine)

Re: You Don't Need UUID

#172

Post by sgarland »

hot_gril wrote: post #151
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 a…

Sortable primarily keys matters very much for any DB clustering on them, e.g. MySQL/InnoDB and SQL Server.

It also matters, albeit to a much lesser extent, to others. Postgres stores tuples in a heap, but the PK is still a B+tree (ish), so an INSERT or UPDATE heavy workload will suffer somewhat.

Re: You Don't Need UUID

#173

Post by happymellon »

beagle3 wrote: post #89
SoftTalker wrote: post #68

Earlier quoted context omitted.

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.

Eventually, everyone converges to babble[0], BIP-39[1], mnemonic[2], diceware, pgp-word list or equivalent. [0] https://bohwaz.net/archives/web/Bubble_Babble.html [1] https://iancoleman.io/bip39/ [2] https://web.archive.org/web/20090918202746/http://tothink.co...

I don't know of anyone who has converged on that.

Although after reading that Babble link it sounds like a great idea for product id's. Scenarios where it is unlikely for people to have to read it out but when they do it's easy enough to convey.

I regret that there are scenarios that we should have converged on it but didn't.

Re: You Don't Need UUID

#174

Post by happymellon »

remram wrote: post #169
masklinn wrote: post #52

Earlier quoted context omitted.

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.

Some alphabets have the disadvantage of generating swears, which might be a problem for your use. Applying filters is a difficult approach. Hex has the advantage there.

> You can't find the product sir? Try typing into the search bar DEADBEEF

Re: You Don't Need UUID

#175

Post by remram »

happymellon wrote: post #174
remram wrote: post #169

Earlier quoted context omitted.

Some alphabets have the disadvantage of generating swears, which might be a problem for your use. Applying filters is a difficult approach. Hex has the advantage there.

> You can't find the product sir? Try typing into the search bar DEADBEEF

If you think of the worse ID you can spell with the full alphabet next, please don't write it here :)

Re: You Don't Need UUID

#176

Post by koromak »

hot_gril wrote: post #2

When it comes to random identifiers, the advantage of uuid4 is mainly that it's a standard thing that everyone understands well, and finding a lib that generates one securely won't require any thought. It's never the ideal solution, but it's often good enough.

I would love to use short UUIDs, but every part of my stack can get a long one with a single, trusted import.

I agree. If there was a shorter standard, I would use that for most cases.

Re: You Don't Need UUID

#177

Post by paulddraper »

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?

> these aren't situations I've ever found myself in

You've never needed to give an order number, member ID, account ID, invoice number, etc?

Re: You Don't Need UUID

#178

Post by paulddraper »

siva7 wrote: post #95
AdamH12113 wrote: post #78

Earlier quoted context omitted.

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

That’s not the only major purpose for a UUID and even if it was, it still would be flat out wrong to claim that almost no application requires that.

The purpose of a universally unique identifier was indeed to be universally unique.

Re: You Don't Need UUID

#179

Post by hot_gril »

sgarland wrote: post #172
hot_gril wrote: post #151

Earlier quoted context omitted.

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

Sortable primarily keys matters very much for any DB clustering on them, e.g. MySQL/InnoDB and SQL Server. It also matters, albeit to a much lesser extent, to others. Postgres stores tuples in a heap, but the PK is still a B+tree (ish), so an INSERT or UPDATE heavy workload will suffer somewhat.

Yeah, you're right. But for those, the typical PK recommendation of bigserial is already time-ordered and mostly packed.

Re: You Don't Need UUID

#180

Post by WorldMaker »

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?

Sort orders are complicated for UUIDs because of the interesting defined structure to them, and of course endian issues.

One fun and useful reference: https://devblogs.microsoft.com/oldnewthing/20190426-00/?p=10...

It's particularly interesting that Microsoft SQL Server was designed to optimize indexing for UUIDv1 machine IDs. That makes a certain amount of sense for a database cluster if IDs are sorted by machine. Of course, developers don't let developers use UUIDv1 in 2023 because those machine IDs are not secure in a general sense and can be a privacy/data leak in the worst cases.

Other databases sort/index UUIDs differently. There's no real "standard" and optimizing the storage of a UUID key is a game of playing to the strengths of your specific database.

(On one project I put some work into matching the much-better-defined ULID sort order to MS SQL Server uniqueidentifier columns for better database locality.)

Post reply on HN