5 ms·

You Don't Need UUID

33 points by henvic 5y ago

mbStavola 5y ago
For those who might have taken an interest in ID schemes, you might want to check out ULID, KSUID, and Snow/Sonyflake.
JI00912 5y ago
Everyone is in such a hurry to point out where others are wrong. You don't need this, don't do that... ("look how smart I am").
- tinus_hn 5y ago
  On a positive note, at least the title isn’t ‘UUID considered harmful’
karmakaze 5y ago
This isn't saying much at all. Could use 88-bits in Base58 encoded chars. A superficial post. Doesn't talk at all about when/when-not to use source-generated random identifiers.
- henvic 5y ago
  I'm the writer. I'm just not very interested in the topic. Just annoyed about UUID overuse enough to write a post. It's also superficial because Tom's video already explains the matter of uniqueness quite well.
  - karmakaze 5y ago
    It was probably the 'dont' title that was off-putting. Using base58 makes good sense and even applies in URLs if using 128-bit UUIDs internally.
    - henvic 5y ago
      No worries. By the way, I added a paragraph in the end saying when I'd use UUID to make it more informative.
vlucas 5y ago
The main advantage with UUIDs (and why I now use them widely everywhere) is with relations, foreign keys, multi-region setups, replication, backups, and the ease of restoring those backups. With sequential IDs, the database state is pretty rigid and cannot easily be restored while still in continuous use, because you can relatively easily run into primary key collisions/violations that can make it incredibly difficult to backup and restore data without taking the whole database offline for writes. Things like scaling out to multi-region and sharding also can get pretty quickly problematic - you end up with duplicate IDs that makes it impossible to easily move data between regions - unless you use a centralized unique ID service (see Twitter's Snowflake for an example). UUIDs just avoids this issue entirely and you can move data around with ease. With UUIDs, things like being able to grab some test data from production, scrub it, insert it into your local database, test with it, and then update it back to staging or production uses trivial normal insert/update operations. With sequential IDs, this task becomes a nightmare of ID collisions and manually altering foreign keys if you do run into duplicate IDs. If anything really does need to be exposed to end users, I typically use another unique string field like username, post slug, etc. rather than directly exposing the UUID to search engine traffic, while still using UUIDs internally everywhere within my database.
- lwhi 5y ago
  I came here to say a similar thing to your last point. The author is explaining the drawbacks of UUID as a user experience problem. UUIDs are built for machines. The solution to providing an identifier for humans doesn't need to involve long—difficult to remember—numbers at all.
- unscaled 5y ago
  It's not like the only two choices you have in the world are UUIDs and auto-incrementing sequential IDs. There are many better alternatives to UUID for the general case in which UUIDv4 is used, that provide some of the following advantages (based on the implementation): - Simpler spec and implementation - Easier to enforce compatibility across implementations (no ambiguity about letter case, order or hyphenation) - Smaller size and better readability - Lexicographically sortable based on time of generation - Deterministic uniqueness guarantee UUID is too much of a jack-of-all-trades-master-of-none. It originally defined many versions (which should have been called "formats") for flexibility, but nowadays only UUIDv4 (and less often UUIDv1) seem to be in use. UUIDv3 and UUIDv5 rely on the insecure MD5 and SHA-1, which, while it seems UUIDv2 and Nil UUIDs were rarely ever used. I hate it when developers are always reaching immediately for UUIDv4 while they almost always have a better choice for their case.
haram_masala 5y ago
There should be a name for this kind of article, this sort of know-it-all hectoring that occurs in so much media now. It goes well beyond the technical fields - think of how many parenting, cooking, and athletics blogs and articles hasten to inform you “you’re doing it wrong.” No doubt this phenomenon successfully plucks at some emotional vulnerability most of us have, and thus brings in the clicks. edit: I also disagree with most of the points this article makes, but that’s just, like, my opinion, man.
- cumwolf 5y ago
  I definitely share your sentiment. it's a different form of click bait.
dudul 5y ago
The Amazon example is so weak. Who the f navigates to a product page by typing the ID in the URL? The only argument I can think of in favor of this proposed alternative is if at some point in your business workflow someone needs to manually type an ID and cannot copy paste it. Sounds pretty rare to me. Even support is now done more and more via chat systems.
- henvic 5y ago
  It's not rare at all, and that was precisely what made me think about writing about it a while ago (and a recent discussion).
- etblg 5y ago
  It's also a URL coming from a link shortener, the slug on it doesn't seem related to any ID on the product page's full URL. The product behind the url could have been using a UUID if they wanted to.
- Zababa 5y ago
  > The Amazon example is so weak. Who the f navigates to a product page by typing the ID in the URL? Two cases: - screenshots - a page that's on your phone that you want to see on your computer Sure, those are not the most frequent, but I'm glad I don't have to type a UUID each time.
nickserv 5y ago
I've had success using xid for user-visible IDs. What's nice is they're shorter than UUID, will sort in order, hides the amount of rows in the table. https://github.com/rs/xid https://github.com/rs/xid
globular-toast 5y ago
Why do people forget that uuids were created to solve a real problem: generating ids on remote/distributed systems where a central authority is not available. This makes distributed systems way easier as you can assume any id you generate anywhere is valid immediately. Any article offering alternatives to uuid needs to start with this problem as a prerequisite.
ianberdin 5y ago
Man, you just reimplemented this: https://hashids.org/go/ https://hashids.org/go/
musicale 5y ago
The thing I like about UUIDs is that they're universal, so if we make contact with aliens they'll be like "don't worry, our UUIDs don't overlap with yours!" The thing I don't like about UUIDs is that they're not necessarily unique across multiple universes.
rrauenza 5y ago
Does anyone else get a weird feeling when generating a uuid to not generate too many because there are only a finite number? Because they are mostly considered unique … I feel like I’m wasting them. I sometimes have this odd cognitive dissonance about it and have to consciously remind myself that this intuition is ridiculous. Is it just me?
- henvic 5y ago
  No. I've got a similar feeling for other silly stuff, like if I create a temporary file and lose its reference. I start thinking, "okay, in 10 years, it'll still be there," even though this is not usually true.
piaste 5y ago
The counterpoint is "You Don't Need to Micro-Optimise Your PK Type". UUIDs offer by far the best developer UX. They're first class objects for most of your tech stack, and they eliminate or massively simplify a lot of potential backend issues, from idempotency to merges to sharding. The main downsides are two: - They're not human friendly. This is a good thing. Surrogate keys should never be exposed to the human user, because what is a 1:1 mapping today may not be 1:1 any longer tomorrow. If you need to let the user input a unique object reference manually, you're free to design that reference with human UX in mind. Maybe it's a set of dictionary words, maybe it's a code with an expiration date, maybe it's the same code but referring to different versions of the object depending on the user. The only people who may need to copy/paste UUIDs manually are database admins, and they will thank you so much more for never bothering them with fixing a pkey clash or an accidental join on the wrong key. - They are less performant than sequential integers. For 99% of projects this is not going to be an actual issue. Once you _do_ find that your queries are being slowed down by the size of primary keys specifically, you have my absolute blessing to add an integer sequence column and make that the primary key.
junon 5y ago
Yet another blanket-statement blog post criticizing one usage of something with opinions disguised as "fact".

33 points by henvic 5y ago

For those who might have taken an interest in ID schemes, you might want to check out ULID, KSUID, and Snow/Sonyflake.

Everyone is in such a hurry to point out where others are wrong. You don't need this, don't do that... ("look how smart I am").

tinus_hn 5y ago
On a positive note, at least the title isn’t ‘UUID considered harmful’

karmakaze 5y ago

This isn't saying much at all. Could use 88-bits in Base58 encoded chars. A superficial post. Doesn't talk at all about when/when-not to use source-generated random identifiers.

henvic 5y ago
I'm the writer. I'm just not very interested in the topic. Just annoyed about UUID overuse enough to write a post. It's also superficial because Tom's video already explains the matter of uniqueness quite well.
- karmakaze 5y ago
  It was probably the 'dont' title that was off-putting. Using base58 makes good sense and even applies in URLs if using 128-bit UUIDs internally.
  - henvic 5y ago
    No worries. By the way, I added a paragraph in the end saying when I'd use UUID to make it more informative.

vlucas 5y ago

The main advantage with UUIDs (and why I now use them widely everywhere) is with relations, foreign keys, multi-region setups, replication, backups, and the ease of restoring those backups. With sequential IDs, the database state is pretty rigid and cannot easily be restored while still in continuous use, because you can relatively easily run into primary key collisions/violations that can make it incredibly difficult to backup and restore data without taking the whole database offline for writes. Things like scaling out to multi-region and sharding also can get pretty quickly problematic - you end up with duplicate IDs that makes it impossible to easily move data between regions - unless you use a centralized unique ID service (see Twitter's Snowflake for an example). UUIDs just avoids this issue entirely and you can move data around with ease. With UUIDs, things like being able to grab some test data from production, scrub it, insert it into your local database, test with it, and then update it back to staging or production uses trivial normal insert/update operations. With sequential IDs, this task becomes a nightmare of ID collisions and manually altering foreign keys if you do run into duplicate IDs. If anything really does need to be exposed to end users, I typically use another unique string field like username, post slug, etc. rather than directly exposing the UUID to search engine traffic, while still using UUIDs internally everywhere within my database.

lwhi 5y ago
I came here to say a similar thing to your last point. The author is explaining the drawbacks of UUID as a user experience problem. UUIDs are built for machines. The solution to providing an identifier for humans doesn't need to involve long—difficult to remember—numbers at all.
unscaled 5y ago
It's not like the only two choices you have in the world are UUIDs and auto-incrementing sequential IDs. There are many better alternatives to UUID for the general case in which UUIDv4 is used, that provide some of the following advantages (based on the implementation): - Simpler spec and implementation - Easier to enforce compatibility across implementations (no ambiguity about letter case, order or hyphenation) - Smaller size and better readability - Lexicographically sortable based on time of generation - Deterministic uniqueness guarantee UUID is too much of a jack-of-all-trades-master-of-none. It originally defined many versions (which should have been called "formats") for flexibility, but nowadays only UUIDv4 (and less often UUIDv1) seem to be in use. UUIDv3 and UUIDv5 rely on the insecure MD5 and SHA-1, which, while it seems UUIDv2 and Nil UUIDs were rarely ever used. I hate it when developers are always reaching immediately for UUIDv4 while they almost always have a better choice for their case.

haram_masala 5y ago

There should be a name for this kind of article, this sort of know-it-all hectoring that occurs in so much media now. It goes well beyond the technical fields - think of how many parenting, cooking, and athletics blogs and articles hasten to inform you “you’re doing it wrong.” No doubt this phenomenon successfully plucks at some emotional vulnerability most of us have, and thus brings in the clicks. edit: I also disagree with most of the points this article makes, but that’s just, like, my opinion, man.

cumwolf 5y ago
I definitely share your sentiment. it's a different form of click bait.

dudul 5y ago

The Amazon example is so weak. Who the f navigates to a product page by typing the ID in the URL? The only argument I can think of in favor of this proposed alternative is if at some point in your business workflow someone needs to manually type an ID and cannot copy paste it. Sounds pretty rare to me. Even support is now done more and more via chat systems.

henvic 5y ago
It's not rare at all, and that was precisely what made me think about writing about it a while ago (and a recent discussion).
etblg 5y ago
It's also a URL coming from a link shortener, the slug on it doesn't seem related to any ID on the product page's full URL. The product behind the url could have been using a UUID if they wanted to.
Zababa 5y ago
> The Amazon example is so weak. Who the f navigates to a product page by typing the ID in the URL? Two cases: - screenshots - a page that's on your phone that you want to see on your computer Sure, those are not the most frequent, but I'm glad I don't have to type a UUID each time.

nickserv 5y ago

I've had success using xid for user-visible IDs. What's nice is they're shorter than UUID, will sort in order, hides the amount of rows in the table. https://github.com/rs/xid https://github.com/rs/xid

globular-toast 5y ago

Why do people forget that uuids were created to solve a real problem: generating ids on remote/distributed systems where a central authority is not available. This makes distributed systems way easier as you can assume any id you generate anywhere is valid immediately. Any article offering alternatives to uuid needs to start with this problem as a prerequisite.

ianberdin 5y ago

Man, you just reimplemented this: https://hashids.org/go/ https://hashids.org/go/

musicale 5y ago

The thing I like about UUIDs is that they're universal, so if we make contact with aliens they'll be like "don't worry, our UUIDs don't overlap with yours!" The thing I don't like about UUIDs is that they're not necessarily unique across multiple universes.

rrauenza 5y ago

Does anyone else get a weird feeling when generating a uuid to not generate too many because there are only a finite number? Because they are mostly considered unique … I feel like I’m wasting them. I sometimes have this odd cognitive dissonance about it and have to consciously remind myself that this intuition is ridiculous. Is it just me?

henvic 5y ago
No. I've got a similar feeling for other silly stuff, like if I create a temporary file and lose its reference. I start thinking, "okay, in 10 years, it'll still be there," even though this is not usually true.

piaste 5y ago

The counterpoint is "You Don't Need to Micro-Optimise Your PK Type". UUIDs offer by far the best developer UX. They're first class objects for most of your tech stack, and they eliminate or massively simplify a lot of potential backend issues, from idempotency to merges to sharding. The main downsides are two: - They're not human friendly. This is a good thing. Surrogate keys should never be exposed to the human user, because what is a 1:1 mapping today may not be 1:1 any longer tomorrow. If you need to let the user input a unique object reference manually, you're free to design that reference with human UX in mind. Maybe it's a set of dictionary words, maybe it's a code with an expiration date, maybe it's the same code but referring to different versions of the object depending on the user. The only people who may need to copy/paste UUIDs manually are database admins, and they will thank you so much more for never bothering them with fixing a pkey clash or an accidental join on the wrong key. - They are less performant than sequential integers. For 99% of projects this is not going to be an actual issue. Once you _do_ find that your queries are being slowed down by the size of primary keys specifically, you have my absolute blessing to add an integer sequence column and make that the primary key.

junon 5y ago

Yet another blanket-statement blog post criticizing one usage of something with opinions disguised as "fact".