44

オフライン データベース ストレージ要件を備えた Web アプリの開発を開始しています。簡単に言えば、アプリは以下で実行できる必要があります。

  • 主要なデスクトップ ブラウザの 1 つ、Chrome 推奨
  • iOS のサファリ
  • Android のネイティブ ブラウザ (V8 および WebKit ベース)

問題は、IndexedDB と Web SQL Database のどちらのテクノロジを選択するかです。

一方、Web SQL データベースに関しては、上記のシナリオのいずれでも使用する準備が整っています。一方、Mozilla は、Firefox がそれを実装することはないと述べており、HTML5ワーキング ドラフトによると、仕様は行き詰まりに達しています。

この仕様は行き詰まりに陥っています。関心のあるすべての実装者は同じ SQL バックエンド (Sqlite) を使用していますが、標準化の道を進むには複数の独立した実装が必要です。別の実装者がこの仕様の実装に関心を持つまで、SQL ダイアレクトの説明は単に Sqlite への参照として残されていますが、これは標準として受け入れられません。独立した SQL バックエンドの実装に関心のある実装者である場合は、編集者に連絡して、方言の仕様を書き、この仕様を前進させてください。

IndexedDB は Mozilla が提唱する代替手段ですが、Firefox 4 でのみ提供される予定です。Microsoft は関心を示しており、Chrome も同様にサポートする予定です。IndexedDB に関する Apple の計画については何も知りません。

個人的には Web SQL Database を選択する傾向がありますが、SQLite に慣れているという理由だけで、SQL のパワーと表現力が好きで、リレーショナル モデルを理解しています。私にとって、IndexedDB は不確実性です。

とはいえ、間違った馬に賭けるのが怖いです。IndexedDB が標準になったとしても、Web SQL データベースのサポートが引き続き存在すると想定しても安全ですか?

(CouchDB に関するメモ: 代替手段としても考えていますか?)

4

6 に答える 6

25

コンピューティングのすべてと同様に、ゲームは「抽象化」です。

SQL ストアとキー/バリュー ストアの両方で機能する適切なレイヤーを考え出すことができれば、理想的には問題から切り離され、特定のブラウザーで適切な実装をサポートできます。データ モデルとアクセス パターンが最小公分母 (つまり、ak/v ストア) に適合しない場合、問題はほぼ解決されます。

いずれかのストアを使用できる場合は、適切なアクセス レイヤーに取り組み、その方向から問題に取り組みます。

バックエンドに ak/v ストアがあるからといって、データを ak/v モデルのみとしてモデル化する必要があるわけではありません。基本的に、バックエンドにあるすべての DB は ak/v ストアです。非常識な量のデータがなければ、多くのことができます。大量のデータでは、飛び越えなければならない可能性のあるフープにより、少量のデータでは見られないパフォーマンスが犠牲になる可能性があります。すべて依存します。

于 2010-10-28T01:57:08.850 に答える
14

WebSQL だけがリストした 3 つの要件すべてをサポートしていることを考えると、選択は簡単ではないでしょうか? Safari や Android の開発ロードマップについての洞察がないため、利用可能なものを使用してください。

于 2010-10-19T20:31:44.043 に答える
9

私は 2016 年 (あなたがこの質問をしてから 5 年後) にこれに返信していますが、WebSQL の非推奨に関するすべてはまだ有効です。一方、IndexedDBはすべての主要なブラウザー ベンダーのサポートを受けています

したがって、ここで同じ決定に直面する可能性がある人は、IndexedDB を使用してください。

ただし、ここで他の人が暗示しているように、そのような決定は必ずしも行わなければならないものではありません。クライアントマシンで利用可能なデータベースを利用するライブラリを簡単に選択 (または作成) できます。

BakedGoodsは、ここで既に提案されているライブラリといくつかの点で異なります。最も適切なのは、使用するストレージ タイプを明示的に指定できるようにすることで、開発者が他の要因 (パフォーマンス特性など) を意思決定プロセスに導入できるようにすることです。

それを使用すると、サポートされているデータベースの種類に関係なく、ストレージ操作を実行するのは簡単です...

... 両方のデータベース タイプに対して適切な操作オプションと同等の構成を指定します。

//If the operation is a set(), and the referenced structures 
//don't exist, they will be created automatically.

var webSQLOptionsObj = {
    databaseName: "Example_DB",
    databaseDisplayName: "Example DB",
    databaseVersion: "",
    estimatedDatabaseSize: 1024 * 1024,
    tableData: {
        name: "Main",
        keyColumnName: "lastName",
        columnDefinitions: "(lastName TEXT PRIMARY KEY, firstName TEXT)"
    }, 
    tableIndexDataArray: [name: "First_Name_Index", columnNames: "(firstName)"]
};

var indexedDBOptionsObj = {
    databaseName: "Example_DB",
    databaseVersion: 1,
    objectStoreData: {
        name: "Main",
        keyPath: lastName,
        autoIncrement: false
    },
    objectStoreIndexDataArray: [
        {name: "First_Name_Index", keyPath: "firstName", unique: false, multiEntry: false}
    ],
};

var optionsObj = {
    conductDisjointly: false, 
    webSQL: webSQLOptionsObj, 
    indexedDB: indexedDBOptionsObj
};

...そして操作を行う:

bakedGoods.set({
    data: [
        {value: {lastName: "Obama", firstName: "Barack"}}, 
        {value: {lastName: "Biden", firstName: "Joe"}}
    ],
    storageTypes: ["indexedDB", "webSQL"],
    options: optionsObj,
    complete: function(byStorageTypeStoredItemRangeDataObj, byStorageTypeErrorObj){}
});

そのシンプルなインターフェースと比類のないストレージ施設のサポートは、一部のストレージ施設固有の構成のサポートが不足しているという犠牲を払っています. たとえば、複数列の主キーを持つ WebSQL テーブルでのストレージ操作の実行はサポートされていません。

したがって、これらのタイプの機能を頻繁に使用する場合は、他の場所を探すことをお勧めします.

ああ、完全な透明性のために、BakedGoods は本当にあなたによって維持されます :) .

于 2016-07-08T23:00:09.877 に答える
7

IndexDB Polyfillが利用可能であるため、IndexDBを使用することをお勧めします。

WebSQL をサポートするすべてのブラウザーは、この方法でIndexDB APIをサポートできます。逆に実装するのは非常に難しいため、何らかの DB API を知っているすべてのブラウザーにリーチしたい場合は、IndexDB が現在の最良の選択です。


注: この質問は古くても関連性があるため、この質問への回答は更新に値すると思います。リンクのみの解決策で申し訳ないので、通常は長続きする目的地へのリンクのみを追加しました: W3C と GitHub

于 2013-08-09T10:21:59.380 に答える
6

iOS での Safari の指定された要件では、WebSQL 以外に代替手段はありません。WebSQL は、Opera や Blackberry などの他のモバイル ブラウザーでサポートされています。IndexedDB があったとしても、WebSQL のサポートを削除することはないと思います。どういうわけか、それらは補完的です。

一方、ブラウザーのストレージ戦争では、IndexedDB が完全に勝利しました。IE と FF には IndexedDB しかありません。皮肉なことに、FF は Sqlite の上に IndexedDB を実装しています。

私が言いたいのは、IndexedDB は単なるキー値ストア以上のものです。インデックスとトランザクションがあります。これら 2 つだけで、結合、条件付き、並べ替えなど、SQL クエリのほぼすべての機能が提供されます。非同期 API のため、最初はわかりません。

IndexedDB のパフォーマンスは WebSQL より優れています。より安全です。JavaScript のユースケースではより柔軟です。最後に使いやすいです。

ケースを説明するために、私のライブラリから擬似コードを使用しますが、IndexedDB API を直接使用することもできます。

'people' ストアには、インデックス フィールド 'name' とリスト インデックス フィールド 'hobby' があります。JSONでは、

people = {
  name: 'Foo Bar',
  email: 'foo@bar.com'
  hobby: ['camping', 'swimming']
};

「キャンプ」が趣味の「人」から名前を検索する。

var req = db.keys('people', 'hobby', IDBKeyRange.only('camping'));
req.done(function(campers) {
  db.keys('people', campers, 'name').done(function(names) {
     console.log(names);
  });
});

このコードの興味深い点は、シリアル化が含まれていないことです。したがって、非常に高速です。

次の例は、フレンドシップ グラフ クエリを示しています。friendshipオブジェクト ストアには、リストされたインデックス付きフィールドが 1 つだけありますfriend_list。これは、People オブジェクト ストア キーをアウト オブ ラインの主キーとして使用します。peopleオブジェクトストアには多くの属性があり、その中にはlocationフィールドがあります。クエリは、'Singapore'を知っmeていて、そこにいる友人のリストを検索することです。other_guy

var q1 = new ydn.db.Iterator('friendship', 'friend_list', IDBKeyRange.only(me));
var q2 = new dn.db.Iterator('friendship', 'friend_list', IDBKeyRange.only(other_guy));
// if location is not indexed, a filtered value query is used.
var q3 = new ydn.db.Iterator('people', new ydn.db.Expression(['"location"', "'Singapore'", '=']));
// if location is indexed, an index query is used.
// var q3 = new ydn.db.Iterator('people', 'location', IDBKeyRange.only('Singapore'));
var current_loop = 2; // start from inner loop
var join_algo = function(keys, index_keys) {
  var advancement = [];
  advancement[keys.length - 1] = null;
  var has_adv = false;
  for (var i = 0; i < keys.length; i++) {
    if (!goog.isDef(keys[i])) {
      // completed iterator
      if (i != 0) {
        advancement[i] = false; // request to restart the iteration
        advancement[i - 1] = true; // advance outer iterator
        current_loop = i - 1;
      } // i == 0 means we are done.
    has_adv = true;
    break;
    }
  }
  if (!has_adv) {
    // continue looping current
    advancement[current_loop] = true;
  }
  return advancement;
}
var result = db.scan([q3, q1, q2], join_algo);
result.done(function(keys, index_keys, values) {
  console.log(values); // should get desire list of friends 
});

繰り返しますが、この結合クエリは単なるキー スキャンであるため、非常に高速です。デフォルトでscanは、並べ替えマージ アルゴリズムを使用して一致するキーを見つけますが、ここでは単純なネスト ループ結合アルゴリズムを示します。したがって、テーブルの結合は可能ですが、結合アルゴリズムをコーディングする必要があります。しかし、ジグザグ マージのような新しいアルゴリズムは、すべての入力が並べ替えられ、カーソルも同様に進むことができ、さらに重要なことに、結合プロセスがデータベースにない外部の知識を利用できるため、Sqlite で可能なよりも高速です。SQL では、結合操作は不透明です。

それ以外にも、IndexedDB はストリーミングやマップ/リデュース処理などの手法を使用できます。

于 2012-11-11T03:54:23.170 に答える
6

データベースのニーズは、キー/バリュー ストアをはるかに超えていますか? そうでない場合は、ローカル ブラウザー ベースのデータベース抽象化用の JavaScript パッケージをいくつか見つけました。そのようなパッケージの 1 つが jStore です。

http://code.google.com/p/jquery-jstore/

最近、ローカルのキー/値ストレージを追加するために使用しました。十分に文書化されており、統合時間はごくわずかでした.APIを介して、フラッシュローカルストレージを含む一連のストレージバックエンドをサポートしています.

CouchDB は優れたソリューションです。つまり、あなたの問題とはまったく一致しない問題です。カウホーンモバイルをチェックしてください。厳密には「Web アプリ」向けではありませんが、仕様にある程度の柔軟性があれば、実行できるデータベース基盤を提供する可能性があります。

于 2010-10-28T00:53:48.777 に答える