CouchDB/PouchDBでの任意のドキュメントの注文

Question

私はCouchDB/PouchDBでスライドショーアプリとして扱えるものを構築しています。それぞれの「スライド」は独自のCouchドキュメントであり、スライドの並べ替えや削除、既存のスライドの間またはスライドショーの最初または最後に追加されます。スライドショーは1枚から1万9000枚に拡大できるため、スペース効率と時間効率に敏感です。

スライドの作成/編集機能を最初に作成しました。スライドの順序を追跡するのが難しいのは完全に過小評価されています。各スライド文書の順序はスライド文書そのものとは完全に独立しているため、文書内に含まれる時間や番号によってソートできるものではないため、これは困難です。

• Efficient way to store reorderable items in a database
• What would be the best way to store records order in SQL
• How can I reorder rows in sql database
• Storing item positions (for ordering) in a database efficiently
• How to keep ordering of records in a database table
• Linked List in SQL

：私は、リレーショナル・データベースに順序を追跡する方法についてStackOverflowの上の数多くの質問を見ます

しかし、これらはすべてのインデックス（すなわち、その後、受注指数1.0および2.0、第三ドキュメント二つの文書を想像の定期的な正規化で、並べ替え/作成/削除のための浮動小数点二次キーを使用してのいずれか

1. を伴いますその間にキー1.5を取得し、次に4番目に1.25、...、31個のドキュメントがその間に挿入され、浮動小数点精度の問題が発生します。
2. スライド文書には、両側の文書の主キーを含むpreviousとnextフィールドがあります。
3. 各文書の並べ替え/挿入/削除ごとにすべての文書を更新する非常に簡単な方法です。

これらはいずれもCouchDBには適していません。＃1は、SQLまたはCouchDBの膨大な偶発的な複雑さを招いています。 ＃2はアトミックトランザクションがないため信頼できません（CouchDBは以前のドキュメントを新しいnextで更新する可能性がありますが、別のクライアントが次の新しいドキュメントを更新している可能性があるため、新しい次のドキュメントの更新は409で失敗し、矛盾した状態で）。同じ理由で、＃3は完全に機能しません。私は評価してる

---

つのCouchDB指向のアプローチは、単にスライドの順序を含むドキュメントを作成します。それは、プライマリ・キー・ツー・オーダー数のハッシュオブジェクトと同様に、配列含まれている場合があります注文番号からプライマリキーに変換し、スライドが並べ替え/挿入/削除されたときにこのオブジェクトを更新するだけです。欠点は、CouchDBがすべての注文変更（並べ替え/挿入/削除）のためにこの潜在的に大きなドキュメントのコピーを保持することです.CouchDBは単一のドキュメントだけを圧縮することをサポートしていません。私は各スライド文書の履歴を保存するのが大好きなのでデータベース全体です。もう1つの欠点は、何千ものスライドの後で、注文に変わるたびにPouchDB/clientからCouchにオブジェクト全体（何キロバイト）が送信されることです。

このアプローチを微調整すると、この注文書を保持し、その上で自動圧縮をオンにするだけの第2のデータベースを作成することになります。2つのデータベース接続を追跡する作業が増え、最終的には大量のデータを配線する必要がありますが、CouchDBでドキュメントを注文する堅牢な方法があります。

---

私の質問は次のとおりです。CouchDBの人々は通常どのようにドキュメントの注文を保存しますか？さらに経験豊富なCouchDBの人々は、私のアプローチで上記のような欠陥を見ることができますか？

Answer 1

@LynHeadleyによるヒントのおかげで、私は文字列の間の辞書的な間隔を細分することができるライブラリを書きました：Mudder.js。これにより、CouchDB内のドキュメントを無限に挿入して移動することができます。新しいキーを自由に作成することで、セカンダリドキュメントのオーバヘッドなしで注文を保存できます。私はこれがこの問題を解決する正しい方法だと思います！

Answer 2

私が読んだことに基づいて、「オーダー・ドキュメント」アプローチを選択します。 （つまり、各スライド文書のidの配列を持つスライドショー文書）これは本当に簡単でユースケースを実現しているので、これらの懸案事項をクリーンで直感的なコードにすることはできません。

あなたは、このドキュメントが非常に大きくなり、その特定のドキュメントの書き込み重視の性質によって複雑になる可能性があります。このため、コンパクションが存在し、ここでの解決策であるため、この時点でCouchDBと対戦するべきではありません。

CouchDBのリビジョン履歴を使用して、データベースに包括的な履歴を保存することは、よくある誤解です。リビジョンは、完全なバージョン管理システムとしてではなく、の書き込み同時実行を支援するためのものです。

CouchDBにはデフォルトで自動圧縮が有効になっていますが、それがなければデータベースのサイズはチェックされません。したがって、このアプローチを使用してドキュメントの履歴を追跡し、代わりに、より安全な別の方法を採用するという考えを放棄する必要があります。 （これらの選択肢のリストはこの回答の範囲外です）