我们在 Notes 数据库上遇到了一个罕见的生产问题。我们的系统在提交期间为请求文档分配一个 ID（实时保存然后提交）。发生的情况是，有时 2 个文档似乎具有相同的 ID，但情况并非如此。
ID 的格式为 YYYY-MM-XXX，其中 YYYY 是当前年份，MM 是数字月份，XXX 是从 001 开始的数字，然后超出。系统在分配 ID 时，会检查同一月份的文档所在的视图。如果它没有看到文档，则在 ID 中分配 001，否则，它会获取视图中的最新文档，获取编号，然后将其增加 1。然后将新编号分配为 ID。
我如何确保在此过程中，我可以根据上述条件分配一个唯一的 ID？该错误非常罕见，我们无法再次模拟它。谢谢您的帮助！
您可以使用 NotesDocument 对象的 lock 方法先锁定文档，然后再更新其中的数字。如果另一个用户进来，脚本需要等到锁被释放。一旦锁定被释放，下一个用户可以锁定它来更新它。
一些代码有助于查看问题所在，但听起来两个用户提交文档时他们都同时查看视图之间存在竞争条件。
在查看视图、获取最新文档、将其加一、将其存储在文档中、保存该文档，然后更新视图以便下次检查视图时，需要花费大量时间最新的文档有更高的数字。您真正需要的是包装所有内容的东西，因此它只能同步发生。说起来容易做起来难。
我建议使用@UNIQUE公式，它（我相信）保证是唯一的，而不是 ID 的 XXX 部分。如果您使用 XXX 部分进行排序，也许您仍然可以将该序列号保存在文档中的某个位置，在最坏的情况下，您将拥有两个具有相同排序键的文档，这可能适合您的需要。
根据@Ken Pespisa 的回答，@Unique 更有可能为您提供独特的价值，但并不能真正保证。如果两个具有相似姓名的用户（即相同的首字母首字母、相同的姓氏前两个字母和相同的姓氏最后一个字母）在完全相同的时间（根据系统时钟）在两台不同的客户端计算机上执行 @Unique，则仍然可能发生碰撞。概率很低，但不是零。
可以在此处的 Andre Guirard 的文章中找到关于为 Notes 文档分配 unqiue 顺序 id 的最终讨论。在我看来，最好的技术是推迟分配唯一的顺序 id，并让运行在服务器上的代理来创建 id。这提供了唯一性的真正保证（只要您正确编码）。权衡是 id 不是立即可用的。