Facebook user_id：big_int，int或string？

Facebook的用户ID上升到2^32 ..这由我算它4294967296Facebook user_id：big_int，int或string？

MySQL的无符号整型的范围是0到4294967295（这是1短 - 或者我的数学是错误的）和无符号的大INT的范围是0到18446744073709551615

INT = 4字节，BIGINT = 8个字节

我是否将其存储为一个字符串？

varchar（10）=？字节

它会如何影响效率，我听说mysql句柄的数字远远胜过字符串（性能明智）。那么你们推荐什么？

来源

2010-01-31 Mark

Facebook的使用64位用户ID。 – Gustav 2013-03-07 11:42:43

@Gustav - 你有这个要求的来源吗？ – FuzzyAmi 2015-03-11 15:59:27

v2.2似乎将user_id定义为字符串。两年前，事实并非如此。 – Gustav 2015-03-12 16:38:29

因为Facebook分配的ID，而不是你，你必须使用 BIGINTs。

Facebook不会顺序分配ID，我怀疑他们有一些分配数字的机制。

我最近修正了这个错误，所以它是一个真正的问题。

我会使它UNSIGNED，只是因为它就是这样。

我会不是使用一个字符串。这使比较痛苦，你的索引比他们需要的更笨重。

来源

2010-01-31 16:32:44

+13

From here：http://wiki.developers.facebook.com/index.php/User_ID“如果您将它存储在MySQL数据库中，请使用BIGINT无符号数据类型。” – 2010-01-31 19:08:18

上面的链接不可用？我无法访问它 – 2012-12-10 11:19:29

是的，我也没有。 – 2013-05-31 14:47:04

-6

除非你预计世界上超过60％的人口会注册，int应该做什么？

来源

2010-01-31 15:05:59 Tarydon

也许我不清楚...我正在做一个Facebook应用程序..所以事实上，Facebook的ID是64位是非常相关......我刚刚从一个帐户得到的ID是......'100000719084526'，所以我猜我的数学在2^32上是错误的。我想bigint这是 – Mark 2010-01-31 15:22:34

看起来像世界上60％的人口将最终注册Facebook。 – 2012-10-09 19:06:13

看起来像，是的。 – Mehdi 2015-07-23 10:33:53

-5

我只会坚持INT。它很容易，它很小，它可以工作，并且如果需要，您可以随时将色谱柱更改为更大的尺寸。

FYI：

VARCHAR(n) ==> variable, up to n + 1 bytes
CHAR(n) ==> fixed, n bytes

来源

2010-01-31 15:08:32 nickf

所以对于脸书我需要超过16个字节作为varchar如果最长的ID可能是15个字符。 – Mark 2010-01-31 15:24:24

否 - int不适用于越来越多的Facebook用户ID，即bigint。 – 2010-01-31 19:09:21

你充满了不好的想法。 – deadprogrammer 2010-05-28 23:09:06

您的数学有点不对......请记住，您可以存储在N个字节中的最大数字是2 ^（N） - 1 ...不是2 ^（N）。有2^N 可能的数字，但是您可以存储的最大数量是1。

如果Facebook使用unsigned big int，那么您应该使用它。他们可能不会按顺序分配它们。

是的，你可以得到一个varchar ...但它会更慢（但可能不如你想象的那么多）。

来源

2010-01-31 16:46:41 Polaris878

您不能再使用INT。昨晚我有两个用户id超出INT（10）。

来源

2010-02-01 02:34:13

我使用bigint来存储facebook id，因为这就是它的原因。

但内部为表的主键和外键，我使用smallint，因为它更小。但也因为如果bigint应该成为一个字符串（通过用户名而不是id来查找用户），我可以轻松地更改它。

，所以我有一个表，看起来像这样：

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

和一个看起来像这样

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

和我的燎页的查询可能是这样的：

select profile_key, profile_name 
from profile 
where fb_profile_id = ?

现在我把profile_key和在下一个查询中使用它

select something_else_key, something_else_name 
from something_else 
where profile_key = ?

无论如何，配置文件表几乎总是被查询，因此我不认为它是一个额外的步骤。

当然，对于一些额外的性能来说，缓存第一个查询也很容易。

来源

2011-04-22 11:35:20 Elmer

将它们存储为字符串。

Facebook Graph API将字符串作为字符串返回，因此如果您希望比较工作而不必投射，则应该使用字符串。海事组织胜过其他考虑。

来源

2012-06-22 21:42:51 dleavitt

如果您在2015年阅读此内容时，Facebook已将其API升级到2.0版本。他们在他们的文档中添加了一个注释，说明他们的ID将会被更改，并且会有一个应用程序范围。所以在未来的将来他们可能会把所有的id变成Alpha数字。

https://developers.facebook.com/docs/apps/upgrading#upgrading_v2_0_user_ids 所以我建议保持类型为varchar，并避免任何未来的迁移阵痛

来源

2015-04-12 07:25:18

“也许”？ “可能性”？为什么“巨大”，顺便说一句？这个答案是随机猜测的ramblings。 IMAO他们不大可能会做这样一个愚蠢的举动（不是他们目前还没有做任何事情，我给你）：他们可能会给每个应用程序提供不同的用户ID。 – 2015-09-04 10:33:42

Facebook user_id：big_int，int或string？

回答

相关问题