4

IndexedDB の W3C 仕様では、キー ジェネレーターを次のように定義しています。

キー ジェネレーターは、キーが必要になるたびに、単調に増加する数値 [原文のまま] を生成します。

現在、（私には）IndexedDB（または、さらに言えば、HTML5クライアント側ストレージオプションのいずれか：WebSQL、localStorageなど）の一般的な使用例は、オフラインで動作するように設計されたアプリです（HTML5と組み合わせて） ApplicationCache)。

このシナリオでは、切断された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 について説明しますが、それも一意のキーの 1 つの形式にすぎません。単調に増加する下位ビットと組み合わせた特定のプレフィックス、全体をランダムに生成する、イーサネットカードアドレスでスコープするなど、さまざまなプロパティを持つ UUID を生成するさまざまな方法があります。

ローカル インスタンスのみに限定されたものを選択することで、IDB は (良くも悪くも) 開発者に「グローバルに」一意のキーを慎重に選択するように強制します。

于 2012-09-20T21:48:16.680 に答える