私は、ドキュメントベースのデータベース（この場合はCouchDB）でいくつかの要件を達成できるかどうかを確認しようとしてきました。2つの一般的な要件：
そして私は、ドキュメントベースのデータベースがこれらの要件に対処するための最良の選択ではないと考え始めています。さらに、ドキュメントベースのデータベースの使用を想像することはできません（おそらく私の想像力はあまりにも限られています）。
これらの要件にドキュメント指向データベースを使用しようとしたときに、ニレに梨を求めているかどうかを説明してもらえますか？
ドキュメント指向の方法でアプリケーションにアプローチする方法を考える必要があります。RDBMSで問題をモデル化する方法を単純に複製しようとすると、失敗します。また、さまざまなトレードオフを行う必要があります。（[ed：これがどのように議論に結びつくかはわかりませんが：] CouchDBの設計では、いつでも失敗する可能性のある多くのノードのアクティブなクラスターがあることを前提としていることを忘れないでください。それの下に？）
それについて考える1つの方法は、コンピューターがなく、紙の文書だけを持っていると想像することです。紙片を渡して効率的なビジネスプロセスをどのように作成しますか？どうすればボトルネックを回避できますか？何かがうまくいかない場合はどうなりますか？
考慮すべきもう1つの角度は、結果整合性です。結果整合性状態になりますが、一定期間は整合性がない場合があります。これはRDBMSの土地ではアナテマですが、現実の世界では非常に一般的です。正規の取引例は、銀行口座からの送金です。これは実際に現実の世界でどのように発生しますか？単一のアトミックトランザクションを通じて、または異なる銀行が相互にクレジットおよびデビット通知を発行することによってですか？小切手を書くとどうなりますか？
それでは、あなたの例を見てみましょう：
これをCouchDBの用語で正しく理解している場合、名前付きの値がすべてのドキュメントで一意であることが保証されているドキュメントのコレクションが必要ですか？ドキュメントは異なるレプリカで作成される可能性があるため、このケースは一般的にサポートされていません。
したがって、実際の問題を調べて、それをモデル化できるかどうかを確認する必要があります。あなたは本当にそれらがユニークである必要がありますか？アプリケーションは同じ値の複数のドキュメントを処理できますか？一意の識別子を割り当てる必要がありますか？あなたはそれを決定論的に行うことができますか？これが必要な一般的なシナリオは、一意のシーケンシャル識別子が必要な場合です。これは、複製された環境で解決するのは困難です。実際、一意のIDが作成された時間に関して厳密に連続している必要がある場合、IDがすぐに必要な場合は不可能です。これらの制約の少なくとも1つを緩和する必要があります。
その投稿に対する最後のコメントは「とても便利です！ありがとう」だったので、ここに何を追加すればよいかわかりません。そこに概説されているアプローチから、まだ問題を引き起こしている何かが欠けていましたか？MrKurtの答えはかなり充実していると思い、競合を減らすための拡張機能を少し追加しました。
データを正規化する必要がありますか？
私は同じボートに乗っており、現在couchdbが大好きで、全体的な機能スタイルは素晴らしいと思います。しかし、正確にいつから、アプリケーション用にernestでそれらを使用し始めます。つまり、はい、私たちは皆、非常に迅速にアプリケーションの開発を開始できます。通常の形式に関する厄介なハングアップはすべて道端に残され、スキーマを使用していません。しかし、「私たちは巨人の肩の上に立っている」というフレーズを作り出します。RDBMSを使用し、スキーマを正規化して使用するのには十分な理由があります。私の古いオラクルの頭は、形のないデータについて考えています。
couchdbの私の主な驚異的な要素は、レプリケーションとバージョン管理システムが連携して機能することです。
私は先月、couchdbのストレージメカニズムを理解しようと頭を悩ませてきました。明らかに、Bツリーを使用していますが、通常の形式に基づいてデータを保存していません。これは、それが本当に賢く、データのビットが複製されていることを認識していることを意味するので、このBツリーエントリへのポインタを作成しましょう。
これまでのところ、base64文字列にストリーミングされるxmlドキュメント、構成ファイル、リソースファイルについて考えています。
しかし、構造データにはcouchdbを使用しますか？私は知りません、これに関してどんな助けも大いに感謝します。
RDFデータや自由形式のテキストを保存するのに役立つかもしれません。
可能性としては、IDで取得できるアイテムの定義を格納するメインのリレーショナルデータベースと、それらのアイテムの説明や仕様のドキュメントデータベースを用意することが考えられます。たとえば、次のフィールドを持つProductsテーブルを持つリレーショナルデータベースを作成できます。
そして、その仕様フィールドには、実際には製品の技術仕様を含むドキュメントへの参照が含まれます。このように、あなたは両方の長所を持っています。
ドキュメントベースのDBは、ドキュメントの保存に最適です。Lotus Notesは一般的な実装であり、Notesの電子メールはその一例です。eコマースやCRUDなど、説明している内容については、実際のDBは、（ドキュメントではなく）インデックスが作成されたデータアイテム/要素の保存と取得に適しています。
CRUD に関して: REST パラダイム全体が直接 CRUD に対応します (またはその逆)。したがって、リソース (URI で識別可能) と基本的な操作セット (つまり CRUD) を使用して要件をモデル化できることがわかっている場合は、かなりの数のドキュメント指向システムが提供する REST ベースのシステムに非常に近い可能性があります。ボックスの。