1

曲とタグがあります。タグは、「録音場所」や「最終録音日」などのタイプにすることができます。

リレーショナル モデルでは、song_id および tag_id 情報を保持する結合モデルがあります。しかし、indexeddb のようなドキュメント ベースの DB では、タグとその情報をドキュメントに直接保存します。固有のタグが多くなければ、長期的には DB の負荷につながらないのだろうか?

別の曲で既に使用されているタグの 1 つが別の曲で必要になる場合は、タグが重複します。

もちろん、ここでもジョイン ストアを使用できますが、これには 2 つのテーブルに対する手動フェッチも含まれます。

モデルについていくつか質問があります。

  1. 曲とタグのストアが必要ですか?
  2. 各曲に付けられたタグの一括更新はどのように行われますか?
  3. これを高速化するには、おそらくどのインデックスが必要ですか?

私の主な側面は、タグ値を介して検索することです（およびタイプでフィルタリングします）。

4

2 に答える 2

1

IDB やその他の NoSQL ストアを適切に使用するための鍵は、結合 ID にとらわれず、各オブジェクト ストアをそれ自体で役立つようにすることです。(そして、インデックスを上手に使用してください!) これは、SQL 風のデータベースが内部でどのように機能するかを覚えておいてください。

一括更新はより困難ですが、これは、よりまれなもの (タグ名の一括変更) の最適化よりも、最も一般的なケース (曲/タグの検索の表示) の最適化に関するものです。

あなたが見ている最も基本的なスキーマは、曲を次のように保存することです:

{ name: "Name of Song"
  id: <song id>
  tags: ["tag1", "tag2", "tag3"] }

また、タグは名前で簡単に識別できます。

{ name: "tagname"
  description: "Some tag description or whatever" }

最初に曲の objectStore を作成します。

var songs = db.createObjectStore("songs", "id");

次に、multiEntry インデックスを作成します。

songs.createIndex("tags", "tags", {multiEntry: true});

次に、タグ objectStore を作成します。

var tags = db.createObjectStore("tags", "name");

本当に必要な場合は自分で結合を行うことができますが、場合によってはオン/オフのものだけです.

var trans = db.transaction(["songs", "tags"]);

var songTags = [];
trans.objectStore("songs").get("songid").onsuccess = function(e) {
    var song = e.target.result;
    for (var i = 0; i < song.tags.length; i++) {
        trans.objectStore("tags").get(song.tags[i]).onsuccess = function(e) {
            var tag = e.target.result;
            songTags.push(tag);
        }
    }
}
trans.oncomplete = function(e) {
     showSongTags(songTags);
}

曲の「タグ」インデックスのおかげで、逆もかなり簡単です。タグ名を直接使用しており、中間の数値 tag_id をいじっていないことに注意してください。

var trans = db.transaction(["songs", "tags"]);

var songs = [];
trans.objectStore("songs").index("tags").openCursor("tag1").onsuccess = function(e) {
    var cursor = e.target.result;
    if (!cursor) return;

    cursor.continue();
    songs.push(cursor.value);
}
trans.oncomplete = function(e) {
     showSongs(songs);
}
于 2012-09-20T21:18:03.327 に答える
0

基本的に、MySQL のようなリレーショナル データベースと MongoDB のようなドキュメント指向データベースのどちらかを選択しなければならないときに直面するのと同じ問題に直面しています。キー自体は言うまでもなく、データの複製はスペースを占有し、1つのコピーを保存して代わりに外部キーを使用する方が間違いなく「第3の形式」です。

そうは言っても、私は IndexedDB の作業でこの両面を経験してきました。ストレージの効率性に関しては、実際にデータにアクセスする方法と比較検討する必要があります。IndexedDB で外部キーのようなスキーマを実現したい場合、基礎となるファイルシステムに 2 つの別個のファイルとして格納されるように、必然的に 2 つ以上のオブジェクト ストアが必要になります。つまり、外部キー データ (ここではタグ) が必要なクエリごとに、少なくとも 2 つのオブジェクト ストア ヒット、おそらく 2 つのトランザクション、およびそれらに関連する余分な io オーバーヘッドなどが必要です。

私はドキュメント指向のアプローチを採用し、キーの省略形 (たとえば、「名前」ではなく「n」) などのトリックを使用して、ストレージへの影響を軽減しようとします。

于 2012-03-23T02:45:07.750 に答える