4

html5 については多くの優れた点がありますが、私が得られないことの 1 つは冗長なストレージ メカニズムです。最初に、キー バリュー ストアである localstorage と sessionstorage があり、1 つはアプリの 1 つのインスタンス (「1 つのタブ」) 用です。 ）、もう一方はそのアプリケーションのすべてのインスタンスに対して機能するため、データを共有できます。どちらもブラウザーを閉じたときに保存され、サイズが制限されています (通常は 5MB)。

しかし、次に「Web SQL データベース」があります。これは、localstorage と同じセキュリティ システム、同じサイズ制限、SQLite のように動作する/SQLite である以外はすべて同じで、テーブルと SQL 構文などすべてを備えています。

残念なことに、それらは同じデータではまったく機能しません。これは、データにアクセスするための 2 つの方法ではありません。実際には、すべての html 5 アプリに対して 2 つのストレージが必要です (デフォルトでは作成されませんが、それでも私の要点はわかります)。

私が知りたいのは、この両方のメカニズムが同時に存在する理由はありますか? それとも、彼らは単に sql と nosql の動きを見て最良のものを選び、「ねじ込み、両方を追加しましょう!」? web sql db 内のテーブルとしてローカル/セッション ストレージを実装しないのはなぜですか?

4

2 に答える 2

5

私の考えでは、localstorageは、そもそもCookieが実行されるべき方法を適切に書き直したものです。非常にシンプルなAPIを備えており、採用の障壁が低くなっています。

Web SQLは非常に強力であり、単純な値を保存するのは非常に困難であるため、ユースケースは大きく異なります。localstorageは、実際にはSQLiteを使用してWebKitに実装されていますが、WebSQLを介して公開されていません。

セッションストレージは、効果的にグローバルスコープにあり、データを他のタブに表示したくないため、データベース内に簡単に実装することはできません。これは一時的なデータであるため、通常はとにかくロットを保存したくないので、トランザクションやクエリは必要ありません。

参照： http ：//www.pubbs.net/200904/webkit/28373-webkit-dev-need-help-making-windowlocalstorage-span-processes.html

于 2010-04-17T12:43:23.533 に答える
0

私は同じ質問を自問しましたが、Chromium wiki から引用した回答は次のとおりです。

Q: なぜこれが LocalStorage を超えるのですか?

A: LocalStorage は、仕様で説明されている「ストレージ ミューテックス」を実装する意思があるかどうかに応じて、本質的に際どいまたは並列処理の災害です。Chromium はそれを実装しないことを決定しました。WebKit 自体は単一のスレッド/プロセスです (つまり、並列処理期間はありません)。

ソース: http://www.chromium.org/developers/design-documents/indexeddb

Web SQL は、オフラインで使用するためにデータベースの構造をローカルにコピーする場合に役立ちます。

ただし、Web SQL は firefox では実装されません: http://us1.campaign-archive.com/?u=168bf22f976f5a68fe5770d19&id=6c2d73c957#standards

Mozilla、Microsoft、および Oracle は、"IndexedDB" の代替案に取り組んでいます: http://www.w3.org/TR/IndexedDB/

Firefox で進行中の作業: https://wiki.mozilla.org/Firefox/Projects/IndexedDB

ストレージのデモ:

于 2010-04-19T21:11:49.493 に答える