4

IndexedDB 的 W3C 规范将密钥生成器定义为：

每次需要密钥时，密钥生成器都会生成一个单调递增的数字 [原文如此]。

现在，（在我看来）IndexedDB（或者，就此而言，任何 HTML5 客户端存储选项：WebSQL、localStorage 等）的常见用例似乎是设计为离线工作的应用程序（与 HTML5 结合使用）应用程序缓存）。

在这种情况下，断开连接的Web 应用程序可能会在其本地数据存储中生成新的对象/记录，这些对象/记录稍后会在与服务器的连接可用时同步到集中式数据库。

此外，多个客户端同步到同一个集中式数据库的任何应用程序通常都需要一种机制来防止 ID 冲突。

UUID（或 GUID）是一个不错的选择，因为它可以在没有任何中央协调的情况下生成唯一的密钥。相比之下，“单调递增的数字”是一个糟糕的解决方案（除非每个客户端都“播种”了一个不太可能与其他用户发生冲突的起始值）。

我发现令人惊讶的是，IndexedDB 规范没有指定（甚至允许将来支持）备用密钥生成器，例如 UUID 生成器。有些人可能会建议答案是根本不使用 IndexedDB 的内置密钥生成器，而是让您的应用程序生成它自己的密钥。

然而，虽然有很多基于 Javascript 的 UUID 生成器可用，但其中许多似乎是基于 Math.random() 的，它在随机性方面具有已知的局限性，因此如果必须使用绝对唯一键，则可能不是一个好的选择保证。

IndexedDB 实现者提供的本机 UUID 生成器（可能）会比应用程序实现/导入的脚本更健壮并且性能更好；有人会想。

那么我在这里错过了什么，还是 W3C IndexedDB 工作组错过了一个机会？

4

2 回答 2

1

这是一个相当有争议的问题，但是，如果您在使用 IndexedDB 几年后想要我的想法，我会说 UUID API 会很好，但它似乎超出了工作组试图实现的范围。

UUID 同名，“普遍”是唯一的。IndexedDB 中唯一性的最高概念是数据级别的对象存储和浏览器级别的数据库。

在实践中，我喜欢在新的数据库或对象存储上重新运行代码时可以获得可预测的、可重复的结果。虽然我可以看到我希望在所有客户端数据库中保持唯一性的情况，但我绝对不希望它成为默认值。

我个人并不要求我的客户端数据库具有普遍的唯一性，但是，无论如何，如果你这样做的话，有很棒的 UUID JS 实现可用。

于 2012-03-23T02:53:07.967 回答
0

objectStore 键对于本地数据库中的 objectStore 来说是唯一的，仅此而已。关于唯一性的任何更高级别的语义实际上都超出了 IndexedDB 的范围。您描述了 UUID，但这只是唯一键的一种形式。有很多不同的方法可以生成具有不同属性的 UUID，包括特定前缀与单调递增的低位相结合、随机生成整个事物、通过以太网卡地址确定范围等。

通过选择仅适用于本地实例的内容，IDB（无论好坏）迫使开发人员仔细选择“全局”唯一键。

于 2012-09-20T21:48:16.680 回答