GUID/UUID数据库密钥的优点和缺点

Question

GUID/UUID数据库密钥的优点和缺点

Mat*_*ard 217 database uuid guid

我曾经在许多数据库系统上工作,如果所有数据库密钥都是GUID/UUID值,那么在数据库之间移动条目会变得更容易.我曾经考虑过几次走这条路,但总会有一些不确定性,特别是在性能和未读出电话的URL方面.

有没有人在数据库中广泛使用GUID？通过这种方式我可以获得哪些优势,以及可能存在的陷阱是什么？

Answer 1

Nic*_*ise 224

好处:

可以离线生成它们.
使复制变得微不足道(与int相反,这使得它非常难)
ORM通常喜欢他们
独特的应用程序.所以我们可以在我们的应用程序(也是guid)中使用我们的CMS(guid)中的PK,并且知道我们永远不会发生冲突.

缺点:

使用空间更大,但空间便宜(呃)
无法按ID排序以获取插入顺序.
在URL中看起来很难看,但实际上,WTF你是否正在将一个真正的数据库密钥放在一个URL中!
更难做手动调试,但不是那么难.

就个人而言,我在任何体系相当的系统中都使用它们作为大多数PK,但我在一个系统上进行了"训练",这个系统在整个地方被复制,所以我们必须拥有它们.因人而异.

我认为重复数据的东西是垃圾 - 你可以获得重复数据但是你这样做.在我工作的地方,代理钥匙通常都不受欢迎.我们使用类似WordPress的系统:

行的唯一ID(GUID /无论如何).用户永远不会看到.
公共ID是从某个字段生成的(例如标题 - 使其成为文章的标题)

更新: 所以这个人得到了很多,并且我认为我应该指出GUID PK的一个重大缺点:聚集索引.

如果GUID上有很多记录和聚簇索引,那么插入性能将为SUCK,因为你会在项目列表中的随机位置插入(这就是要点),而不是在结尾(这很快)

因此,如果您需要插入性能,可以使用auto-inc INT,并在您想与其他人共享时生成GUID(即,将其显示给URL中的用户)

[WTF你在把一个真正的数据库密钥放在URL中吗？？]不确定为什么会让你烦恼.你还会用什么？看看Stack Overflow ...它在整个地方的URL中都有IDENTITY值,它运行得很好.在URL中使用数据库密钥不会阻止您强制执行安全性. (178认同)
记住一件事,人们经常更改页面,问题,论坛标题.对于搜索引擎优化,可以在URL中使用类似小ID的内容,这样如果标题发生变化,您仍然知道将来自旧URL的人转发到何处.`example.com/35/old-and-busted`刚刚成为`example.com/35/new-hotness`而你是应用程序只需检查标题并转发用户301. (25认同)
不,它没有,但是像SEO这样的东西通常会更好,如果没有钥匙 - 特别是像GUID一样长的东西.当然,它可以很容易地解决,所以我猜这是一个过于笼统的声明 (20认同)
索引GUID既昂贵又缓慢,这使得它们非常不适合主键. (9认同)
很好的答案,如果您还添加有关使用GUID的性能缺点的信息,那将是很好的; 例如,加入,排序和索引将比使用整数慢.Guids非常棒,但是当性能至关重要时,它们会付出代价. (7认同)
"在我工作的时候,代理键通常是不受欢迎的" - 但你所描述的建议你使用UUID作为代理键.此外,如果你只将代理键与自然键对比,那么可以说UUID是你可能拥有的最不自然的键.所以只是为了澄清,代理与自然完全是另一场辩论,这两种方法都没有任何内在错误. (2认同)
如果您使用 UUID1，您将获得递增的键，因为时间戳占据最高有效位。您可以将 UUID1 作为数字进行比较以确定生成顺序。它们也是数据库索引友好的，因为新生成的键总是在最后。（注意：UUID1 包括生成服务器的 MAC 地址，因此如果您不想透露这一点，请使用 UUID1 的多播变体。） (2认同)

Answer 2

Tro*_*vin 13

@Matt Sheppard:

假设您有一张顾客表.当然,您不希望客户不止一次存在于表中,或者您的销售和后勤部门会发生很多混淆(特别是如果客户的多行包含不同的信息).

因此,您拥有唯一标识客户的客户标识符,并确保客户(在发票中)知道标识符,以便客户和客户服务人员在需要通信时具有共同参考.为了保证没有重复的客户记录,您可以通过客户标识符上的主键或客户标识符列上的NOT NULL + UNIQUE约束向表中添加唯一性约束.

接下来,出于某种原因(我无法想到),系统会要求您将GUID列添加到customer表并将其作为主键.如果现在客户标识符列没有唯一性保证,那么您要求整个组织将来遇到麻烦,因为GUID始终是唯一的.

一些"架构师"可能会告诉你"哦,但我们在应用层中处理真正的客户唯一性约束!".对.关于通用编程语言和(特别是)中间层框架的时尚一直在变化,并且通常永远不会超出您的数据库.并且您很有可能在某些时候需要访问数据库而无需通过本应用程序.==麻烦.(但幸运的是,你和"架构师"早已不复存在,所以你不会在那里清理混乱.)换句话说:在数据库中保持明显的约束(在其他层中,如果你有时间).

换句话说:可能有充分的理由将GUID列添加到表中,但请不要试图降低您在真实(==非GUID)信息中保持一致性的抱负.