My question is more advisory than technical.
I'm writing a Facebook app in which I am fetching some information about the user, including facebook_id.
I was wondering if I should keep the user id as INT or VARCHAR in the MySQL database?

- 24,937
- 4
- 62
- 81

- 6,595
- 12
- 42
- 64
-
IMAO you should switch the accepted answer to Gustav's. – o0'. Sep 04 '15 at 10:30
7 Answers
Facebook uses 64-bit integers (bigint) for their user ids. So you use Bigint UNSIGNED in MySQL.
Edit: Facebook usernames is not the same thing as the user id. The username is of course varchar but will not be returned as the id.

- 2,902
- 1
- 25
- 31
-
9Facebook says the user ID is a string. Perhaps they may switch to using alphanumeric. So use a string. https://developers.facebook.com/docs/graph-api/reference/user – Doug S Aug 15 '15 at 02:51
-
For those of you reading this in order to determine the appropriate data type for Facebook ID's, use a **string**. The JSON data structure returned uses a string data type (_e.g._, _not_ a numeric data type). – Lemonseed May 29 '16 at 17:52
-
4Their reference says `numeric string`, which means while the type is a string, the content is a number. So storing it as `UNSIGNED BIGINT` is fine, while storing as `varchar` will just make lookup and comparison more hassle. If FB does change to to `alphanumeric` which they haven't, there will be deprecation warnings and dev blog posts about it. – Dan Sep 08 '16 at 02:59
Although unlikely, facebook could change the format of their ID's, so to make it future proof, I'd use a varchar.

- 3,248
- 3
- 28
- 49
-
2Correct answer. Facebook says the user ID is a string. Perhaps they may switch to using alphanumeric. So use a string. https://developers.facebook.com/docs/graph-api/reference/user – Doug S Aug 15 '15 at 02:52
-
@DougS Wrong answer: Gustav's one is correct, and it has been posted on the same day so it's not even a "they changed idea later" problem. – o0'. Sep 04 '15 at 10:29
-
2@Lohoris: Gustav's answer is unsafe. The Facebook doc I linked to states the user ID is a "numeric **string**". It is not a "bigint" as Gustav states in his answer. Your app will break once FB starts using alphanumeric ids, or if they return a numeric string that doesn't fit in a bigint. Much safer to store the ids as strings, just as Facebook defines it. – Doug S Sep 10 '15 at 04:25
-
1@Lohoris Anywhere that references the user ID as an `int` is outdated. It is definitely not an `int` as Facebook now has more user ID's (including biz page ID's, etc) than can even fit in an `int`. – Doug S Sep 19 '15 at 22:34
similar question to: Facebook user_id : big_int, int or string?
"I would not use a string. That makes comparisons painful and your indexes clunkier than they need to be."
-
1Finally, I saved it as an unsigned int. Mostly because of the sorting and comparing. Take a look at link above. – Sharon Haim Pour Aug 21 '11 at 13:06
-
@Sharon Haim Pour - You need to use bigint(20). There are UID's that are longer than int(10). – Phillip Aug 21 '11 at 13:21
-
-
Facebook says the user ID is a string. Perhaps they may switch to using alphanumeric. So use a string. https://developers.facebook.com/docs/graph-api/reference/user – Doug S Aug 15 '15 at 02:51
To quote facebook's upgrade notes regarding graph API v2.0 (effective May 2015):
All IDs are strings. In v1.0, IDs were often large numbers.
Which (to me) implies that userids are not guaranteed to be numbers. In fact, facebook recommend that you use strings:
https://developers.facebook.com/docs/graph-api/reference/v2.2/user#fields
Name:id
Description: id The id of this person's user account.This ID is unique to each app and cannot be used across different apps(...)
type: string
Although I must admit I've never seen an alphanumeric id.
-
FWIW, after scouring the web, I was able to find a facebook product manager that admitted that uids were BigInt at the moment (Feb 2015) and that they have no plans on changing this for the V2.0 (May 2015), but it could change afterwards. – FuzzyAmi Mar 15 '15 at 06:53
-
4Now it says `numeric string` instead, which basically means they are having fun at us, I guess? – o0'. Sep 23 '15 at 09:32
Use BIGINT(64) to store Facebook User IDs.
Here you go: https://developers.facebook.com/blog/post/45/

- 846
- 10
- 11
For new data types, as they are grahp obj ID, I believe it is safe to save them as BINT. However, for old "id", e.g. pic, save them as string (you can easily see that they are in the format xxxxxx_xxxxxxxx)

- 1,161
- 1
- 8
- 15
I'd use INT, because it's not so big. Searching in INT is faster and betterfor ordering

- 50,477
- 20
- 96
- 125
-
Searching for an int is faster if you're counting CPU cycles, but you're not likely to be able to measure the difference in any resolution that matters. Additionally, as @Rich S says, choosing the INT type locks you into what their ID looks like today and potentially causes problems in the future -- not only that FaceBook could change their ID format (they can), but also should the same code base be repeated for some other site with a non-pure-int ID format. – mah Aug 21 '11 at 12:08
-
6
-
1Yep. I've seen systems break because developers used INT for fb_uid's. It basically produced loads of duplicate "maxint"-numbers. Use BIGINT(64) UNSIGNED to be safe. – Joe Oct 21 '13 at 12:43