IndexedDB 的 W3C 规范将密钥生成器定义为:
每次需要密钥时,密钥生成器都会生成一个单调递增的数字 [原文如此]。
现在,(在我看来)IndexedDB(或者,就此而言,任何 HTML5 客户端存储选项:WebSQL、localStorage 等)的常见用例似乎是设计为离线工作的应用程序(与 HTML5 结合使用)应用程序缓存)。
在这种情况下,断开连接的Web 应用程序可能会在其本地数据存储中生成新的对象/记录,这些对象/记录稍后会在与服务器的连接可用时同步到集中式数据库。
此外,多个客户端同步到同一个集中式数据库的任何应用程序通常都需要一种机制来防止 ID 冲突。
UUID(或 GUID)是一个不错的选择,因为它可以在没有任何中央协调的情况下生成唯一的密钥。相比之下,“单调递增的数字”是一个糟糕的解决方案(除非每个客户端都“播种”了一个不太可能与其他用户发生冲突的起始值)。
我发现令人惊讶的是,IndexedDB 规范没有指定(甚至允许将来支持)备用密钥生成器,例如 UUID 生成器。有些人可能会建议答案是根本不使用 IndexedDB 的内置密钥生成器,而是让您的应用程序生成它自己的密钥。
然而,虽然有很多基于 Javascript 的 UUID 生成器可用,但其中许多似乎是基于 Math.random() 的,它在随机性方面具有已知的局限性,因此如果必须使用绝对唯一键,则可能不是一个好的选择保证。
IndexedDB 实现者提供的本机 UUID 生成器(可能)会比应用程序实现/导入的脚本更健壮并且性能更好;有人会想。
那么我在这里错过了什么,还是 W3C IndexedDB 工作组错过了一个机会?