Facebook 用户 ID (UID) 是否是 Facebook 应用程序面向未来的关键？
Facebook UID 对于一个用户来说始终是唯一的吗？例如，如果用户永久删除了其帐户，Facebook 是否可以为新用户重用其 UID？或者甚至可以将其用作无生命内容的 ID，例如城市或本地企业的页面？我可以使用 UID 作为 Facebook 应用程序中用户的主键，而不用担心它们将来与其他内容关联吗？
我无法找到任何保证它们将来不会被重复使用的文档。
这个问题或多或少问同样的事情 ( Facebook应用程序数据库问题：存储我自己的用户 ID 还是仅使用 Facebook UID？） 然而，答案并没有提供任何证据证明 UID 在未来将保持唯一性。
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 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
答案取决于 Facebook UID 的含义。如果您正在谈论与用户帐户关联的无意义的整数值，那么您可能没问题。如果您谈论的是用户名，那么这是一个有意义的键，我认为您需要小心。
如果你能在 Facebook API 文档中找到一份由马克·扎克伯格 (Mark Zuckerberg) 签署的声明，表明这种情况不会发生，那并不重要。如果您使用有意义的键值，那么总会存在该键将来可能发生更改的一些风险。
风险可能很小。 “未来”可能比你的应用范围还要长。但在未来的某个时候，Facebook 肯定会决定收回已不活跃或已删除的用户 ID，以便其他同名的人可以拥有它。
以下是一些证据证明这种情况可能会发生。
如果您想确保您的应用程序能够区分今年的 Facebook.com/Harman 和明年（或 2015 年等）的区别，那么您应该保留自己无意义的 PK，并将其与有效的 PK 映射到 Facebook 密钥。日期范围，如下所示：
这是绝对确保您的 PK 唯一的唯一方法，不仅因为它只在表中出现一次，而且因为它始终引用完全相同的人/帐户。
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:
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.
UID 将始终是唯一的。
通常的做法是将主键 (PK) 设置为自动增量，它被归类为“已在此表中创建的行数”，并且不考虑已删除的行。因此，即使添加 3 行然后删除它们，自动增量仍然设置为 4，这将是插入的下一行的 ID。
这可能是“它没有在任何地方记录，它在任何地方都有记录”的情况：P 这是应该始终暗示的事情之一； PK 永远不会因为不同的事情而使用两次。句号。
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.
每当您使用其他人管理的数据时，您就很容易被那些人搞砸。
您可能会认为社会安全号码 (SSN) 对于个人来说是唯一的。但在几十年前，社会保障管理局实际上不止一次分配过这些数字。
Facebook 不太可能搞砸这件事。但由于人为错误甚至恶意，这种情况也可能发生。
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.