Are facebook User IDs (UIDs) a future proof key for Facebook Apps?

Will Facebook UIDs always be unique to one user? For example, if a user permanently deleted their account, might Facebook reuse their UID for a new user? Or maybe even use it as the ID for something inanimate like the page for a City or a Local Business? Can I use UIDs as the primary key for Users in a Facebook app without worrying about开发者_Python百科 them being associated with something else in the future?

I haven't been able to find any documentation that guarntees that they will not be reused in the future.

This question more or less asks the same thing ( Facebook app database issue: Store my own User ID or just use Facebook UID? ) However, the answer does not provide any proof that UIDs will remain unique into the future.

---

The answer depends on what you mean by the Facebook UID. If you are talking about the meaningless integer value associated with a user account, then you are probably OK. If you are talking about the User Name, then that is a meaningful key and I think you need to be careful.

It doesn't matter if you can find a statement in the Facebook API documentation saying that it won't happen, signed in the blood of Mark Zuckerberg. If you use a meaningful key value then there is always some risk that the key could change in the future.

The risk may be small. The "future" may be longer than the scope of your application. But sometime in the future Facebook may surely decide that they would like to reclaim a user ID that has been inactive or deleted so that someone else with the same name can have it.

Here is some proof that it can happen.

If you somehow want to be sure that your application can tell the difference between this year's Facebook.com/Harman and next year's (or 2015's etc.) then you should keep your own meaningless PK and map it to the Facebook key along with an effective date range, like so:

FB_USER_KEY_MAP
  my_pk_value IDENTITY,
  fb_pk_value,
  effective_date,
  expiry_date

This is the only way to be absolutely sure that your PK is unique not only insofar as it only appears once in your table, but also insofar as it always refers to exactly the same person/account.

---

The UID will ALWAYS be unique.

It's common practice to set up your Primary Key (PK) as auto-incrememnet, which is classed as "the number of rows that have been created in this table", and takes no account of rows removed. Thus, even if you add 3 rows then delete them, the auto-increment is still set to 4, which will be the ID of the next row inserted.

This might be a case of "it's not documented anywhere, it's documented everywhere" :P It's one of those things that should always be implied; a PK will never be used twice for different things, ever. Full stop.

---

Whenever you use data managed by somebody else, you are vulnerable to the possibiility that those people will screw up.

You would figure that Social Security number (SSN) would be unique to an individual. But in decades long gone, the Social Security Administration actually assigned the numbers more than once.

Facebook is unlikely to screw this one up. But it could happen, as the result of human error or even malice.