Facebook user_id : big_int, int or string?

Question

Facebook\'s user id\'s go up to 2^32 .. which by my count it 4294967296.

mySQL\'s unsigned int\'s range is 0 to 4294967295 (which is 1 short - or my math is wrong) a

Answer 1

Because Facebook assigns the IDs, and not you, you must use BIGINTs.

Facebook does not assign the IDs sequentially, and I suspect they have some regime for assigning numbers.

I recently fixed exactly this bug, so it is a real problem.

I would make it UNSIGNED, simply because that is what it is.

I would not use a string. That makes comparisons painful and your indexes clunkier than they need to be.

Answer 2

You can't use INT any more. Last night I had two user ids that maxed out INT(10).

Answer 3

I would just stick with INT. It's easy, it's small, it works and you can always change the column to a larger size in the future if you need to.

FYI:

VARCHAR(n) ==> variable, up to n + 1 bytes
CHAR(n) ==> fixed, n bytes

Answer 4

Store them as strings.

The Facebook Graph API returns ids as strings, so if you want comparisons to work without having to cast, you should use strings. IMO this trumps other considerations.

Answer 5

Unless you expect more than 60% of the world's population to sign up, int should do?

Answer 6

If you are reading this in 2015 when facebook has upgraded their API to 2.0 version. They have added a note in their documentation stating that their ids would be changed and would have an app scope. So maybe there is huge possibility later in the future that they might change all the ids to Alpha numeric.

https://developers.facebook.com/docs/apps/upgrading#upgrading_v2_0_user_ids So I would suggest to keep the type to varchar and avoid any future migration pains