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