uuid in doubt

[hujun8610]

As mentioned in the gitbook, Returning response with uuid is a better practice. But backend developer usually use database to store data.As we know,It is not recommended to use uuid in the database,So how to solve the problem or haveing good suggestion.

[brandur]

It may indeed be worthwhile to amend this one slightly, even if only to make it clear that it's certainly not a slam dunk to use UUIDs.

The way I see it, UUID advantages:

• Operational errors, even across different tables/resources, are incredibly difficult to do by accident. Two different resources in two different tables might share the ID 23, but when it comes to UUIDs, no entity shares an ID with anything else in the database. This has legitimately saved me a couple times as I've run an UPDATE against the wrong table (again, accidentally).
• Scales well beyond a single master database.

Sequence/serial advantages:

• Much improved data locality in that new data will land in the same nodes in the B-tree/pages on disk. If you have a table with a lot of INSERTs happening, sequences will be far more performant I/O-wise.
• More human friendly in that it's easy to copy or remember a comparatively short integer ID compared to a UUID.

[geemus]

Good callouts. Do you think we should move from a recommendation to an explanation of the tradeoffs then?

[holly-hacker]

It's worth mentioning that UUIDs also bring security benefits. An online store may leak information about their sales numbers if they expose integer IDs for their order numbers, allowing competitors to monitor their activity. Malicious actors may also use them to enumerate/scrape resources which may not be desirable. I'd personally recommend UUIDs over integers unless you expect to never expose these ids or have a good reason to use them.

EDIT 2024/09/16: UUIDs also match integers' data locality improvements if you use v7 UUIDs, which sort by the date when they were created.

[geemus]

I'd welcome a PR if you'd like to draft some updates.