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

Your math is a little wrong... remember that the largest number you can store in N bytes is 2^(N) - 1... not 2^(N). There are 2^N possible numbers, however the largest number you can store is 1 less that.

If Facebook uses an unsigned big int, then you should use that. They probably don't assign them sequentially.

Yes, you could get away with a varchar... however it would be slower (but probably not as much as you are thinking).

Answer 2

I use a bigint to store the facebook id, because that's what it is.

but internally for the primary and foreign keys of the tables, i use a smallint, because it is smaller. But also because if the bigint should ever have to become a string (to find users by username instead of id), i can easily change it.

so i have a table that looks like this:

profile
- profile_key smallint primary key
- profile_name varchar
- fb_profile_id bigint

and one that looks like this

something_else
- profile_key smallint primary key
- something_else_key smallint primary key
- something_else_name varchar

and my queries for a singe page could be something like this:

select profile_key, profile_name
from profile
where fb_profile_id = ?

now i take the profile_key and use it in the next query

select something_else_key, something_else_name
from something_else
where profile_key = ?

the profile table almost always gets queried for almost any request anyway, so i don't consider it an extra step.

And ofcourse it is also quite ease to cache the first query for some extra performance.