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

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

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

优点:

  • 可以离线生成它们。
  • 使复制琐碎(而不是int的,这使得它很难)
  • ORM通常喜欢它们
  • 独特的应用程序。 所以我们可以在我们的应用程序(也guid)中使用我们的CMS(guid)中的PK,并知道我们永远不会发生冲突。

缺点:

  • 更大的空间使用,但空间便宜(呃)
  • 不能通过ID来获取插入顺序。
  • 可以看起来丑陋在一个URL,但真的,跆拳道你在做一个真正的数据库密钥在URL!
  • 很难做手动debugging,但并不难。

就个人而言,我在大多数体系中都使用它们,但是我已经在一个遍布全球的系统上进行了“训练”,所以我们必须拥有它们。 因人而异。

我认为重复数据的东西是垃圾 – 你可以得到重复的数据,但你这样做。 代理键通常皱在我曾经工作过的地方。 尽pipe我们使用类似WordPress的系统:

  • 该行的唯一标识(GUID / whatever)。 用户永远不可见。
  • 公共ID是从一些领域产生(例如标题 – 使其成为文章的标题)

更新:所以这个人得到了很多+1,我想我应该指出一个GUID PK的聚集索引的一个很大的缺点。

如果在GUID中有很多logging和一个聚簇索引,那么插入的性能就会下降,因为你插入项目列表中的随机位置(多数民众赞成在点),而不是在最后(这是快速)

所以,如果你需要插入性能,也许使用一个自动增加的INT,并且如果你想与其他人分享它(例如,在一个URL中显示给用户)

@马特·谢泼德:

假设你有一张顾客的桌子。 当然,您不希望客户不止一次地在表格中存在,否则在您的销售和物stream部门(特别是有关客户的多行包含不同信息的情况下)会出现很多混淆。

因此,您有一个唯一标识客户的客户标识符,并确保标识符由客户(在发票中)知道,以便客户和客户服务人员在需要沟通的情况下有一个共同的参考。 为了保证不存在重复的客户logging,可以通过客户标识符上的主键或客户标识符列上的NOT NULL + UNIQUE约束来为表添加唯一性约束。

接下来,由于某种原因(我想不出来),你被要求添加一个GUID列到客户表,并使主键。 如果客户标识符列现在没有唯一性保证,那么您在整个组织中要求将来出现问题,因为GUID始终是唯一的。

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

换句话说:向表中添加GUID列可能有很好的理由,但是请不要为了降低您在真实 (==非GUID)信息中的一致性的野心。

主要优点是你可以创build唯一的ID而不需要连接到数据库。 和id是全球唯一的,所以你可以轻松地结合来自不同数据库的数据。 这些看起来好处不大,但为我省了很多工作。

主要的缺点是需要更多的存储空间(现代系统没有问题),而且这些ID不是人类可读的。 debugging时这可能是一个问题。

有一些性能问题,如索引碎片。 但是那些是可以解决的(吉米·尼尔森的梳子指南: http : //www.informit.com/articles/article.aspx? p = 25862)

编辑合并我的这个问题的两个答案

@Matt Sheppard我认为他意味着你可以复制具有不同GUID作为主键的行。 这是任何types的代理键的问题,而不仅仅是GUID。 而且就像他说的那样,通过给非关键列添加有意义的唯一约束,就可以很容易地解决这个问题。 另一种方法是使用自然键,那些有真正的问题..

如果将GUID用作“uniqifiers”,GUID可能会在将来造成很大的麻烦,让重复的数据进入您的表格。 如果您想使用GUID,请考虑仍在其他列上维护UNIQUE约束。

为什么没有人提到性能? 当你有多个连接,所有基于这些讨厌的GUID的performance会穿过地板,一直在:(

如果您还将该列用作聚集索引(一种相对常见的做法),则还需要考虑另一个小问题,即将GUIDS用作主键。 由于guid的性质,你打算插入反正不会开始顺序,因此当你插入的时候它们会被分页等。 只是要考虑如果系统将有高IO …

主密钥的IDS抗的GUID

GUID作为主键的成本 (SQL Server 2000)

神话,GUID与自动增量 (MySQL 5)

这真是你想要的。

UID优点

  • 每个表,每个数据库,每个服务器都是唯一的
  • 允许轻松合并来自不同数据库的logging
  • 允许在多个服务器上轻松分发数据库
  • 您可以在任何地方生成ID,而不必往返数据库
  • 无论如何,大多数复制scheme都需要GUID列

GUID缺点

  • 比传统的4字节索引值大4倍; 如果你不小心,这可能会有严重的性能和存储影响
  • debugging麻烦(其中userid ='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
  • 为了获得最佳性能,生成的GUID应该是部分顺序的(例如,SQL 2005上的newsequentialid()),并使用聚簇索引