37

I've seen multiple sizes and I don't want to waste server memory on a MySQL field which is reserving too much space for too many characters. What's the biggest they can get and will this ever change?

Kara
  • 6,115
  • 16
  • 50
  • 57
Farid El Nasire
  • 1,753
  • 4
  • 15
  • 17
  • 2
    There is no limit whatsoever specified in the documentation. As to "will it ever change" - that's Facebook we're talking about; drastic API changes are commonplace. So, although the UIDs are pretty central, I wouldn't trust FB *not* to change it, anytime in the future, because they just might feel so. Better treat it as an opaque string of characters. – Piskvor left the building Sep 27 '11 at 09:27
  • 3
    For Mysql, use UNSIGNED BIGINT ; see: http://stackoverflow.com/questions/2172126/user-id-big-int-int-or-string – Costa Jan 08 '14 at 22:11

4 Answers4

65

This is how integer overflows, integer->string migrations etc happen, by making datatypes too restrictive. Splash out on a few bytes for a 128b varchar and save yourself the hassle down the road. If your user base gets so massive that you need to be worrying about how many bytes you will save by crunching data types of UIDs, consider yourself a huge success and that is a problem you will be happy to solve.

Short answer, I dont think anyone will be able to answer your question, "ever" is a long time and who knows how many entities facebook will have enslaved by then.

I'll end with a quote from one who said it best;

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
—Donald E. Knuth
evandrix
  • 6,041
  • 4
  • 27
  • 38
markdsievers
  • 7,151
  • 11
  • 51
  • 83
  • This is a good answer. I just had this exact problem. Previously all the Facebook IDs in my system were no more than 10 digits in length, however Facebook recently changed this so IDs are 15 digits in length. I started seeing multiple users with the same Facebook ID and didn't recognize the "ID" was actually the max integer value. I changed my field to a varchar and gave it plenty of padding for posterity. – Gavin Jun 16 '14 at 05:08
  • 2
    +1 for VARCHAR because of this: parseInt("10208914157005637") in Javascript returns 10208914157005636!!! – JCKödel Nov 27 '17 at 21:09
3

How could you ever be sure that this will never change? Better make it a varchar.

Johan Kotlinski
  • 25,185
  • 9
  • 78
  • 101
2

Currently, Facebook UIDs are 64 bits integers. But I can't guarantee that won't change one day.

Maxime Chéramy
  • 17,761
  • 8
  • 54
  • 75
-10

The Facebook UID will never change because it is a unique identifier in their database. If it changed then facebook would cease to work

Walter Cecil Worsley IV
  • 464
  • 1
  • 11
  • 20
  • 4
    don't bet on that, they can e.g. decide to switch to using alphanumeric UIDs without having to update the existing ones.. it's unlikely change of course, but never say never... – ivanhoe Nov 05 '13 at 05:25
  • 3
    I know this is an old post, but Google brought me here. Facebook UIDs does change at this moment! Every facebook app sees the same users with different UIDs. The combination AppId+UserId should never change, as it was designed to be handled by facebook apps, so you probavly can rely on it. At this moment, my tests points user id as 17 characters long. At this moment, I'm declaring it on MySQL as facebook_id varchar(50), as you can never know what the next user's id can be. :-o – Alexandre T. May 25 '15 at 13:58