リレーショナルデータベースの代わりにドキュメントベースのデータベースを使用する必要があるのはなぜですか？
なぜリレーショナルデータベースを使用するのではなく、CouchDBのようなドキュメントベースのデータベースを使用する必要があるのですか。ドキュメントベースのデータベースがリレーショナルデータベースよりも適している典型的な種類のアプリケーションまたはドメインはありますか？
おそらくあなたはすべきではありません:-)
2番目に明らかな答えは、データがリレーショナルでない場合に使用することです。これは通常、データを一連の列として記述する簡単な方法がないことを示しています。良い例は、紙の文書を実際に保存するデータベースです。オフィスのメールをスキャンします。データは、スキャンされたPDFであり、常に存在するメタデータ（スキャン、スキャン、ドキュメントの種類）と、いつか存在する多くのメタデータフィールド（顧客番号、サプライヤ番号）があります。 、注文番号、ファイル保存期限、OCRedフルテキストなど）。通常、今後2年以内にどのメタデータフィールドを追加するかは事前にわかりません。CouchDBのようなものは、リレーショナルデータベースよりもこの種のデータの方がはるかに優れています。
また、最近ではほとんどすべてのプログラミング言語に組み込まれているHTTPクライアントを除き、CouchDBのクライアントライブラリは必要ないという事実も個人的に気に入っています。
おそらく最も明白な答え：RDBMSを使用しても痛みを感じない場合は、そのままにしてください。常にRDBMSを回避して作業を完了する必要がある場合は、ドキュメント指向のデータベースを一見する価値があります。
より詳細なリストを確認するには、 このリチャードジョーンズの投稿 をご覧ください。
CouchDB（ website から）
RESTful JSON APIを介してアクセス可能なドキュメントデータベースサーバー。一般に、リレーショナルデータベースは、RESTサービスを介して単純にアクセスされるのではなく、はるかに複雑なSQL APIを必要とします。これらのAPI（JDBC、ODBCなど）は非常に複雑です。RESTは非常に簡単です。
アドホックでスキーマフリーで、フラットなアドレス空間。リレーショナルデータベースには、複雑で固定されたスキーマがあります。テーブル、列、インデックス、シーケンス、ビューなどを定義します。 Couchは、このレベルの複雑で高価で脆弱な高度な計画を必要としません。
分散型で、双方向の競合検出および管理を備えた堅牢な増分レプリケーションを備えています。一部のSQL商用製品はこれを提供します。 SQL APIと固定スキーマのため、これは複雑で、難しく、高価です。 Couchの場合、シンプルで安価に見えます。
クエリ言語としてJavascriptを使用するテーブル指向のレポートエンジンを備えた、クエリ可能およびインデックス可能。 SQLおよびリレーショナルデータベースも同様です。ここに新しいものはありません。
そう。なぜCouchDBなのか？
- RESTはJDBCやODBCよりも簡単です。
- スキーマより単純なスキーマはありません。
- シンプルで安価に見える方法で配布されます。
他のサーバーのデータを愚かに保存して提供するため。
この数週間、私はフィード（delicious、flickr、github、Twitter ...）をポーリングしてcouchdbに保存するライフストリームアプリで遊んでいます。 couchdbの長所は、オーバーヘッドなしで元のデータを元の構造に保持できることです。各ドキュメントに「クラス」フィールドを追加し、ソースサーバーを保存し、各ソースのJavaScriptレンダリングクラスを作成しました。
サーバーを別のサーバーと通信する場合は常に、スキーマを制御できないため、スキーマレスストレージが最適化されます。おまけとして、couchdbはサーバーとクライアントのネイティブプロトコルを使用します-JSONは表現に、HTTP REST=転送に。
迅速なアプリケーション開発が思い浮かびます。
スキーマを絶えず進化させているとき、MySQL/SQLiteでスキーマを維持しなければならないことにイライラしています。私はまだCouchDBを使いすぎていませんが、RADプロセス中にスキーマを進化させるのがどれほど簡単であるかが好きです。
非リレーショナルデータベースを使用したくない場合は、多対多の関係が多数ある場合です。特に結合関係にメタデータが必要な場合は、これらの種類の関係を中心に適切なMapReduce関数を作成する方法についてまだ理解していません。よくわかりませんが、CouchDBマップ関数がデータベースで独自のクエリを呼び出すことができるとは思いません。無限ループを引き起こす可能性があるからです。
レコードごとに同じサイズのフィールドを持つテーブルにデータを保存する必要がない場合は、ドキュメントベースのデータベースを使用します。代わりに、特定の特性を持つドキュメントとして各レコードを保存する必要があります。最初に「テーブルを変更」する必要なく、任意の長さの任意の数のフィールドをいつでもドキュメントに動的に追加できます。ドキュメントベースのフィールドには、複数のデータを含めることもできます。