I knew of a trucker once, who when he was starting his transport business, marked his first truck with "Number 8".
It never hurts to make people believe you are bigger and better than you really are.
Things you should do now (2011)
111–115 of 115 posts
Re: Things you should do now (2011)
#112Earlier quoted context omitted.
If you're going to use a key space in the trillions, and partitioned and sparsely populated rather than sequential... isn't that just reinventing what the UUID already is? A UUID is just a 128-bit integer, with creation algorithms designed to partition that space by things that already have enough entropy to need no further synchronization. What you're proposing sounds like roll-your-own-UUID, which might be similarl…
Don't try to compare this to rolling your own crypto. The stakes are nowhere near the same for IDs as for crypto, and the stakes are the defining feature of the "don't roll your own crypto" meme.
Yes I'm comparing it and you don't get to tell me I can't.
It's not about the stakes. It's the idea that in rolling your own, you're going to get it wrong, or otherwise do worse than existing ways that have already solved the same problem.
Re: Things you should do now (2011)
#113Earlier quoted context omitted.
integer ids are still often used internally for database primary keys with UUIDs being the done thing for external interfaces. Personally I've never experienced the "whole class of bugs" that starting with a big integer is supposed to solve. I'm not using PHP so maybe that's why?
I've run into one, but it was pretty dumb. Multitenant application using the account ID as the first element in the URL on a Rails app. when it got to account 404, my address.com/404 went to the static 404 page rather than account 404. That user was pretty confused for awhile.
I don't know rails, but that is just terrible design. address.com/accounts/404 is what the devs should have used, and "404" is a response code and an error page, not a URL you redirect/rewrite URLs to.
Re: Things you should do now (2011)
#114Earlier quoted context omitted.
Don't try to compare this to rolling your own crypto. The stakes are nowhere near the same for IDs as for crypto, and the stakes are the defining feature of the "don't roll your own crypto" meme.
Yes I'm comparing it and you don't get to tell me I can't. It's not about the stakes. It's the idea that in rolling your own, you're going to get it wrong, or otherwise do worse than existing ways that have already solved the same problem.
That applies to literally all code. So if it's not about the stakes, only experts are ever allowed to deploy code of any kind that they've written themselves.
Re: Things you should do now (2011)
#115Things you should never do: use integers as ID's. This is literally a solved problem, and the solution is UUIDs, which were invented for exactly this job.
Integers are by far the best primary key material possible. Only for lack of discipline do they seem inferior to alternatives. See a prior book I wrote on HN regarding this: https://news.ycombinator.com/item?id=25309248 The current domain model I am working with utilizes a global integer sequence to key all entities. This implicitly eliminates the class of bugs where the same keys of different types overlap and would…
> The benefits of an integer key vs a guid key are quite profound when you get into the academics of information theory. They provide implicit creation order of things, whereas GUIDs cannot.
We had this requirement, but a semi-UUID solution is desirable in a distributed setting. Ref prior art by Instagram engineering: https://archive.is/Dydln
(from your linked comment)
> If you are worried about security (i.e. someone hitting sequential keys in your URLs), then this is arguably an application problem. You should probably generate an additional column that stores some more obfuscated representation of the primary key and index it separately.
Yep, see: https://github.com/ai/nanoid and https://hashids.org/