我们有一个将其数据存储在 SQL Server 中的应用程序。每个表都有一个 bigint 主键。我们过去完全按需生成这些，即当您要插入新行时，首先调用生成下一个 ID，然后再进行插入。
我们添加了在离线模式下运行的支持:如果您的连接断开(或 SQL Server 断开)，它会将数据保存到本地文件，直到您重新联机，然后同步您从那时起所做的一切。
这需要能够在客户端生成 ID。现在，它不再向 SQL 询问下一个 ID，而是询问下一个百、千或 10,000 个 ID，然后将范围存储在本地，因此在这 10,000 个用完之前它不必再询问更多。它实际上会将它们分成更小的 block ，因此当 5000 用完时，它仍有 5000 的缓冲区，并且它可以再请求 5000。
问题是，一旦它上线，我们就开始收到主键违规的报告。我们将数据存储在 Windows 注册表中的 HKEY_CURRENT_USER 中(注册表中保证用户能够写入的唯一位置)。因此，经过一些研究，我们发现 HKEY_CURRENT_USER 是漫游配置文件的一部分，因此 ID 可能会被旧版本覆盖。特别是当用户同时登录到网络上的多台计算机时。
因此我们重新编写了生成 ID 的部分，以从用户的“本地设置”目录中读取/写入文件。当然，这不应该被旧版本覆盖。但即使是现在，我仍然偶尔会看到主键违规。在这种情况下，我们唯一能做的就是删除文件中的任何键，将用户踢出应用程序，并且在他们获得新的 ID 范围之前不要让他们回来。
但如果“本地设置”不安全，那会是什么？有没有什么地方可以在保证不会回滚到旧版本的计算机上存储持久值？谁能解释为什么“本地设置”不符合这个标准？
我已经考虑过类似 GUID 的解决方案，但它本身就存在问题。
最佳答案
在像你这样的分布式环境中，你最好的选择是使用 GUID
关于sql - 在数据库外存储主键生成器的安全方法？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5071909/