Hacker News Reader

Comment by simonw | Hacker News Reader

My rule of thumb is to use strings for all IDs that belong to external systems. A bunch of people got burned in the same way a few years ago when Flickr photo IDs rolled past 32 bits.

View on HN

Still surprised people use incrementing ints for ids over uuids for web apis that may become immense.

http://www.ietf.org/rfc/rfc4122.txt

uuids are made just for this purpose, string based, never bigger than 40 characters (with dashes and curly braces).

Most products use uuids or Microsoft's name for them guids.

I prefer my ID's universally unique. I worry that globally unique ID's won't scale as we begin to colonize other planets. (yes, its a joke.)

Stating it is a joke kind of ruined the joke.

we don't use incrementing ids, but needed ids that increase over time (so that you can sort tweets by them). hence, snowflake: http://github.com/twitter/snowflake

You don't even need to go that far. For non-critical applications (i.e., your web app), you can randomly generate a small string, say 12 bytes, using base-62 characters (A-Za-z0-9) to serve as a probably unique user ID (with VERY high probability).

Heard of GUIDs? Make part of it a timestamp, and the chance of collisions goes down astronomically further.

In some cases, including a timestamp in an ID can be giving away information considered private. Sure, you could just hash the resultant ID, but then you're getting back to random digits anyway.

My rule of thumb is that if you apply math operators to it, then it should be a number, if not, make it a string. There are still rare cases where you use a number as an id because you're trying to save on space, but typically not for a web app. I've also found that there are even cases where you don't need record ids. Statistical data, for example.

The twitter api includes string representations of the ids already and we encourage everyone to use those rather than the numeric ones.

yeah. don't get why everyone didn't just convert to string after the last twitpocalypse

Yeah, only problem is that is very inefficient from a storage perspective. It depends on the situation of course. If it's only a few thousand per day for example, not a big deal, but otherwise that could end up biting you in the ass hard after a while.

Reply on news.ycombinator.com