-1

我的应用程序的用户可以通过 Facebook 进行身份验证，因此我将 facebook uid 存储在我的数据库中，当用户登录时，我需要像这样查询我的数据库：

SELECT * FROM users WHERE uid = _SOME_UID_;

现在uid列是 VARCHAR，但我认为我需要将其转换为某种数字类型 BIGINT。

为什么我认为我需要这样做：

  1. 处理器时间：通常使用数字（过滤/索引）的操作总是比使用字符串的相同操作快

  2. 存储：数字小于对应的字符串

  3. 嗯... oauth-argument Facebook 身份验证是我要使用的唯一身份验证类型（实际上，这是一个画布应用程序） - 所以我不需要关心非数字的 UID

问题是：

  1. 我对吗？
  2. Facebook 有朝一日可以开始使用非数字 uid 吗？
4

2 回答 2

1

我会坚持使用 VARCHAR。

虽然它当然可以存储为一个，但我认为 Facebook UID 并不是一个真正的数字。它是一个字符集合，恰好都是数字——但它是一个标识符，而不是一个要被操纵的数字。

我想知道性能差异到底是什么。找出这一点，做出决定会更容易。

于 2013-03-29T19:03:39.967 回答
1

这取决于几个因素。首先，您的数据收集可能有多大，我们谈论的是数千个 UID 还是数百万个？如果您不担心项目的规模，然后尝试找到最小的容器（一个大整数），那么您会更担心能够随着变化进行扩展。

So now you need to choose VarChar of a reasonable size which will take any format of UID and be happy- this includes leading zeros and bigInt which is easier to sanitise for but unfriendly to leading zeros and letters.

If you know that the UID is always a non-leading zero or zero padded number then you can get slightly better security by sanitising by way of casting to type. That and size are all the benefits of bigInt.

VarChar has the downfall of size - you need to know the biggest UID length before you start but leading zeros, letters and other unexpected content can be handled with the small exception that you are now cleaning a string.

From a programming point of view it makes very little odds as a UID is just a label that is unique. With an index on it I should not imagine that there is any speed difference in MySQL at least not with the common engines it might be using.

So best is simply a product of what you need most from the data.

于 2013-03-30T00:08:45.387 回答