猿问
下载APP

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

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


有没有人在数据库中广泛使用GUID?通过这种方式我会得到什么好处,以及可能存在的陷阱是什么?


弑天下
浏览 61回答 3
3回答

达令说

好处:可以离线生成它们。使复制变得微不足道(与int相反,这使得它非常难)ORM通常喜欢他们独特的应用程序。所以我们可以在我们的应用程序(也是guid)中使用我们的CMS(guid)中的PK,并且知道我们永远不会发生冲突。缺点:使用空间更大,但空间便宜(呃)无法按ID排序以获取插入顺序。在URL中看起来很难看,但实际上,WTF你是否正在将一个真正的数据库密钥放在一个URL中!(这一点在下面的评论中有争议)更难做手动调试,但不是那么难。就个人而言,我在任何体系相当的系统中都使用它们作为大多数PK,但我在一个系统上进行了“训练”,这个系统在整个地方被复制,所以我们必须拥有它们。因人而异。我认为重复数据的东西是垃圾 - 你可以获得重复数据但是你这样做。在我工作的地方,代理钥匙通常都不受欢迎。我们使用类似WordPress的系统:行的唯一ID(GUID /无论如何)。用户永远不会看到。公共ID是从某个字段生成的(例如标题 - 使其成为文章的标题)更新: 所以这个人得到了很多,并且我认为我应该指出GUID PK的一个重大缺点:聚集索引。如果GUID上有很多记录和聚簇索引,那么插入性能将为SUCK,因为你会在项目列表中的随机位置插入(这就是要点),而不是在结尾(这很快)因此,如果您需要插入性能,可以使用auto-inc INT,并在您想与其他人共享时生成GUID(即,将其显示给URL中的用户)

明月笑刀无情

假设您有一张顾客表。当然,您不希望客户不止一次存在于表中,或者您的销售和后勤部门会发生很多混淆(特别是如果客户的多行包含不同的信息)。因此,您有一个唯一标识客户的客户标识符,并确保客户(在发票中)知道标识符,以便客户和客户服务人员在需要通信时具有共同参考。为了保证没有重复的客户记录,您可以通过客户标识符上的主键或客户标识符列上的NOT NULL + UNIQUE约束向表中添加唯一性约束。接下来,出于某种原因(我无法想到),系统会要求您将GUID列添加到customer表并将其作为主键。如果现在客户标识符列没有唯一性保证,那么您要求整个组织将来遇到麻烦,因为GUID始终是唯一的。一些“架构师”可能会告诉你“哦,但我们在应用层中处理真正的客户唯一性约束!”。对。关于通用编程语言和(特别是)中间层框架的时尚一直在变化,并且通常永远不会超出您的数据库。并且您很有可能在某些时候需要访问数据库而无需通过本应用程序。==麻烦。(但幸运的是,你和“建筑师”早已不复存在,所以你不会在那里清理混乱。)换句话说:在数据库中保持明显的约束(在其他层中,如果你有时间)。换句话说:可能有充分的理由将GUID列添加到表中,但请不要试图降低您在真实(==非GUID)信息中保持一致性的抱负。

芜湖不芜

主要优点是您可以创建唯一的ID而无需连接到数据库。id是全球唯一的,因此您可以轻松地组合来自不同数据库的数据。这些似乎是小优点,但过去为我节省了大量工作。主要的缺点是需要更多的存储空间(在现代系统上不是问题),并且id不是真正的人类可读性。这在调试时可能是个问题。有一些性能问题,如索引碎片。但那些是可以解决的(jimmy nillson的梳子指南:http://www.informit.com/articles/article.aspx? p = 25862 )编辑合并了我对这个问题的两个答案@Matt Sheppard我认为他意味着您可以将具有不同GUID的行复制为主键。这是任何类型的代理键的问题,而不仅仅是GUID。就像他说的那样,通过向非键列添加有意义的唯一约束可以很容易地解决它。另一种方法是使用自然键,那些有实际问题。
打开App,查看更多内容
随时随地看视频慕课网APP
我要回答