Guid（随机整数）与聊天应用程序的常规整数主键答案

【问题标题】：Guid(Random ints) vs regular int primary key for chat applicationGuid（随机整数）与聊天应用程序的常规整数主键
【发布时间】：2012-12-26 16:23:37
【问题描述】：

我不是在问一个笼统的“guid vs ints 哪个更好”的问题。我知道，或者至少认为我知道他们都有特定的场景，其中一个比另一个更好。但是我确实有一个特定的场景，我正在编写一个聊天应用程序。我启动应用程序时所有主键都是整数。但是在做了一些研究之后，我意识到我可能在应用程序中存在安全漏洞，因为我正在将主键传递给用户的浏览器以获取不同的实体请求，例如聊天室、谈话者等。人们会同意可以猜测后续主键，因此用户可以更改其他用户的会话和状态。为了防止这种情况发生，我正在考虑使用 guid 作为我的主键，但后来另一个想法击中了我。关于性能的思考。由于这是一个聊天应用程序，如果应用程序承受重负载，例如同时有 10 或 100 万用户同时使用 guid，那么使用 guid 真的会降低我的性能。我真的没有足够的信息来在这里做出选择。简而言之，我的问题是，我是否需要将主键更改为 guid 以帮助更难猜测主键，或者是否有其他方法可以在不求助于 guid 的情况下保护我的应用程序。如果问题不够清楚，请告诉我，我会澄清，谢谢。

【问题讨论】：

我认为 GUID is 是一个 int，尽管它的位数比大多数编程语言为整数提供的位数多，而一个通常以十六进制形式表示。您的问题的核心真的是关于随机 ID（例如 uuidgen 可能生成）和顺序 ID 之间的选择吗？如果是，为什么不这么说呢？
@HighPerformanceMark...感谢您提供的信息，我应该澄清一下...但是是的，这就是我的意思。

标签： database performance security primary-key guid

【解决方案1】：

不，您不需要将主键更改为 GUID。这不一定会给您任何额外的安全性，可以说是security by obscurity。

使用 GUID 使攻击者无法猜测其他用户的 ID 或聊天室的唯一密钥。但是，如果 ID 被传输，它不会阻止他们看到 ID，然后能够执行您当前担心的任何操作。

相反，当用户对数据库发出请求时，您必须验证他们是否被允许访问该数据。例如，他们应该只能检索自己的用户信息，或其他用户的基本用户信息（例如句柄，但不能检索电子邮件地址）。

【讨论】：