今天下午与我的同事讨论了将 GUIDS 与 IDENTITY 字段作为主键的优点。来自大数据背景，我本能地选择了 IDENTITY，但他们更面向 Web，更喜欢 GUIDS。
大多数优点和缺点都有很好的记录，并在此进行了巧妙的总结：
http://databases.aspfaq.com/database/what-should-i-choose-for-my-primary-key.html
但我的同事提出了一个我无法回答的问题，谷歌也无法回答，我认为这是一个有趣的问题。在单页应用程序样式系统中，javascript 模型（即 Breeze JS）通常用于在提交之前临时保存许多可能的数据库更改，以减少服务器往返。这增加了表的 IDENTITY 字段由于同时另一个插入而增加的机会。当然，当您尝试提交时，这可能会导致混乱。
那么在这种情况下，特别是考虑到 SPA 通常在数据库级别没有性能瓶颈，使用 GUID 通常更明智吗？还是我们夸大了堆叠多个更改以提交的潜在问题？
正如 Jay 所说，不用担心商店生成的 Id 的竞争条件。Breeze 使用临时密钥，这些临时密钥被解析为数据库层上的永久密钥。那里不用担心。
但我通常也更喜欢 Guid，原因完全不同，受我作为客户端开发人员所面临的问题的影响，对服务器端效率的兴趣/担忧较少。
在分布式应用程序（如 Breeze 应用程序）中使用 Guid 的最佳原因是离线场景更容易支持。当实体被导出和导入时，临时键（Breeze 处理得很好）不能很好地保存......就像在客户端存储（例如，浏览器存储）中存储未保存的新实体时一样。即使您不离线，此模式也很有用；当用户在工作流程中移动时，我经常将未保存的工作存储在本地……以防他/她意外关闭浏览器。
老实说，Guids 对于服务器端的人来说真的不是什么大问题。您可以使用受时间影响的 Guid（例如 GuidComb）来解决碎片问题。随着更快的硬件和更好的数据库，存储和索引性能问题正在减少。唯一需要查看代理键的人是开发人员；我们受苦受苦。
我写了很多演示，毫无疑问，使用整数身份密钥可以让作者和读者更轻松地完成这项工作。我不认为演示提供了合理的指导。
在实践中，我使用混合的关键数据类型，即使它们不是身份。我的静态参考实体（查找：状态、美国各州等）和很少更改的实体（产品目录中的产品）通常是整数键。它们更容易阅读和设置（顺便说一下更容易存储）。客户经常创建的实体（例如，订单）使用 Guid。
没有一个答案。您的里程会有所不同。在这里插入陈词滥调。
不确定我是否在回答您的问题，但如果您在 Breeze 中使用标识列，那么 Breeze 会在保存之前自动为任何新实体生成一个临时 id 值。在服务器上，一旦生成了“真实”id，Breeze 会将临时到真实 id 的映射发送回客户端，并修复客户端 id 以匹配新的“真实”id。身份值的生成在保存期间完全由数据库处理，因此在使用身份列时意外重用 id 并导致提交失败并没有真正的问题。工件是所有“添加”记录（涉及身份或服务器生成的密钥的记录）的 id 将在保存成功结束时自动更改。
也就是说，如果您使用 Guids，那么这一切都不是必需的。无需修复，客户端 ID 不会因保存而更改。与标识列相比，Guid 确实往往更大一些，并且“可能”表现出更少的局部性（因此可能导致保存速度变慢）。即它们通常分散在数据库中，而不是附加到现有表中。（顺序指南部分弥补了这一点）。
这两种技术都是可行的并且有支持者。尽管如此，我个人更喜欢Guids。我喜欢简单。