代码之家 › 专栏 › 技术社区 › yukondude

对于使用UUID作为数据库行标识符,特别是在web应用程序中,您有什么看法?

uuid web-applications database

yukondude · 技术社区 · 18 年前

为了简单和(假定的)速度,我一直倾向于在数据库中使用长整数作为主键。但是当使用 REST

http://example.com/user/783

然后假设也有ID为782、781、…、2和1的用户。假设所讨论的web应用程序足够安全,可以防止用户输入其他号码来查看未经授权的其他用户,则简单的顺序分配代理密钥也会“泄漏”实例总数(比此实例早),在这种情况下,可能是用户的特权信息。(例如,我是stackoverflow中的用户#726。)

会吗 UUID

http://example.com/user/035a46e0-6550-11dd-ad8b-0800200c9a66

虽然不十分简洁,但屏幕上显示的用户信息较少。当然,这有点“默默无闻的安全”的味道,这并不能取代适当的安全,但它看起来至少有点安全。

这一好处是否值得为web可寻址对象实例实现UUID的成本和复杂性?我认为我仍然希望使用整型列作为数据库PK,只是为了加速联接。

更新:对于那些询问仅在URL中使用用户名的人(例如。, http://example.com/user/yukondude ),对于具有唯一名称的对象实例来说,这很好,但是如何处理大量只能通过数字识别的web应用程序对象呢?订单、交易、发票、重复图像名称、堆栈溢出问题。。。

15 回复 | 直到 18 年前

Douglas Tosi 18 年前

我不能说你问题的网络方面。但是UUID对于n层应用程序来说非常有用。PK生成可以分散:每个客户机生成自己的PK,而不存在冲突风险。而且速度差通常很小。

确保数据库支持高效的存储数据类型(16字节,128位)。

我在Firebird中广泛使用了它们,并推荐使用。

Adam Tuttle 18 年前

值得一提的是,我看到一个长时间运行的存储过程(9秒以上)只需从GUID主键切换到整数,运行时间就会下降到几百毫秒。这并不是说

SQLMenace 18 年前

我可以回答您,在SQL server中,如果您使用uniqueidentifier(GUID)数据类型并使用NEWID()函数创建值,您将由于页面拆分而得到可怕的碎片。原因是使用NEWID()时生成的值不是顺序的。SQL 2005添加了newSequatial()函数来解决这个问题

仍然使用GUID和int的一种方法是在表中使用GUID和int,以便GUID映射到int。GUID在外部使用,但int在DB内部使用

例如

457180FB-C2EA-48DF-8BEF-458573DA1C10    1
9A70FF3C-B7DA-4593-93AE-4A8945943C8A    2

1和2将用于web应用程序中的联接和GUID。这个表将非常窄,查询速度应该非常快

Jonathan Arkell 10 年前

为什么要将主键与URI结合起来?

为什么不让您的URI键是人类可读的(或不可用的,取决于您的需要),并让您的主索引基于整数,这样您就可以两全其美了。很多博客软件都是这样做的,其中条目的公开id由“slug”标识,数字id隐藏在系统内部。

编辑: Stackoverflow并不完全使用我描述的系统,请参见下面的Guy评论。

Josh 18 年前

http://example.com/user/783

为何不:

http://example.com/user/yukondude

哪一个对人类更友好,不会泄露一点点信息?

Andrea Bertani 18 年前

这将是一种双向加密,您将确保两个不同的ID始终具有不同的加密。
如果你花时间生成足够的ID并获取模式,那么解码显然是很容易的,但是,如果我正确理解了你的问题,你只想不太容易地泄露信息。

AviD 18 年前

我们使用guid作为所有表的主键,因为它兼作MS-SQL-Server复制的RowGUID。当客户突然在世界的另一个地方开了一间办公室时,这就很容易了。。。

Brian Lyttle 18 年前

我认为GUID不会给你带来很多好处。用户讨厌冗长、难以理解的URL。

创建可以映射到URL的较短ID,或强制实施唯一用户名约定( http://example.com/user/brianly ).那里的人 37Signals

顺便说一句,您可以强制数据库从基值开始创建整数ID。

Michael Barker 18 年前

这还取决于您对应用程序的关注程度。对于n层应用程序,guid/uuid更易于实现,并且更易于在不同数据库之间进行移植。为了生成整数键,有些数据库本机支持序列对象,有些则需要自定义序列表的构造。

整数键(我没有数字)可能为查询和索引性能以及空间使用提供了优势。直接数据库查询也更容易使用数字键,复制/粘贴更少,因为它们更容易记住。

GateKiller 18 年前

我使用一个学生管理系统,该系统使用整数形式的UUID。它们有一个表,其中包含下一个唯一ID。

虽然从架构的角度来看,这可能是一个好主意,但它使日常工作变得困难。有时需要进行批量插入,而拥有UUID会使这变得非常困难,通常需要将游标而不是简单的SELECT语句写入。

Rizwan rhys 4 年前

我在真实的网络应用程序中尝试了这两种方法。

作为一名开发人员,看到顺序整数,知道一些关于总记录数的信息正在泄漏,感觉有点糟糕,但老实说,大多数人可能不在乎,而且这些信息对我的业务从来都不是很重要。

在我看来,拥有长而丑陋的UUID URL更像是对普通用户的一种关闭。

Dan TheCodeJunkie 18 年前

Matt user129975 9 年前

我认为在您的情况下,使用GUID将是更好的选择。它占用更多空间,但更安全。

Rizwan rhys 4 年前

YouTube使用11个字符和base64编码,这提供了11^64的可能性,并且它们通常非常易于编写。我想知道这是否会比UUID提供更好的性能。UUID转换为base 64的大小将是我认为的两倍。

更多信息可在此处找到: https://www.youtube.com/watch?v=gocwRvLhDf8

-1

user2106945 13 年前

只要你使用具有高效存储的DB系统,现在的HDD还是很便宜的。。。

根据模糊性考虑安全性在形成模糊URI和使用表、记录和列定义的安全性构建规范化数据库时,它们非常适合。GUID不能出错,请尝试使用基于整数的id。