Incremental IDs work best, but if you want you can hash a UUID which will work for your use case: % uuidgen B14818B6-4219-43BD-82EF-8421EC1AFBCF % echo "B14818B6-4219-43BD-82EF-8421EC1AFBCF" | shasum -a 256 00ea501d47789ac5eb559f10d631b3f6df8f82b5cba9c1f9d234b705d89f1704
Ask HN: How should I create a unique id for entries that aren't incremental?
11–15 of 15 posts
Re: Ask HN: How should I create a unique id for entries that aren't incremental?
#12"where there won't be any collision even if there are 1 billion+ entries" This is a really complicated topic, and there are multiple ways to handle what you're doing. It really depends on your read/write ratios, typical volume, growth rate, and the underlying DB software you're using. Because there are so many considerations that require knowing real-world use cases, it's a premature optimization. Are you going to ha…
Hmm, well right now users are complaining it's too easy to view other people's boards because the url is https://www.taskfort.com/view/10 The only way to not view a person's board is if it's private.. There are some services that for their pages will have id's that are 7 or so characters long, and very compact, the uuid you're referencing seems kind of ugly. I would still keep my incremental ID in the table as a PK,…
http://kvz.io/blog/2009/06/10/create-short-ids-with-php-like...
Re: Ask HN: How should I create a unique id for entries that aren't incremental?
#13Re: Ask HN: How should I create a unique id for entries that aren't incremental?
#14Earlier quoted context omitted.
That's still incremental though. It just looks different.
bigint gives you 9.2 quintillion options before you run into a collision. Which is obviously not forever proofed, but certainly future proofed.
OP needs a way to generate a random ID without checking that the ID has already been used -- s/he wants a UUID. Bigint is FAR too small to do that a billion times without a collision.
Re: Ask HN: How should I create a unique id for entries that aren't incremental?
#15"where there won't be any collision even if there are 1 billion+ entries" This is a really complicated topic, and there are multiple ways to handle what you're doing. It really depends on your read/write ratios, typical volume, growth rate, and the underlying DB software you're using. Because there are so many considerations that require knowing real-world use cases, it's a premature optimization. Are you going to ha…
> However, there are other reasons to use non-incremental IDs (security, for one). That's just security by obscurity, with proper authorization checking it doesn't matter.
You can have the same issue with scrapers. It's much easier for scrapers to get all your pages if you use sequential numbers for unique IDs.
Yes, a search engine could index the pages, but the big engines will obey your robots.txt, and the small engines will never know that you exist most likely.
So s/he's not trying to "secure" anything as much as just hide it.