202

リレーショナル データベースを使用する代わりに、CouchDB のようなドキュメント ベースのデータベースを使用する必要があるのはなぜですか。ドキュメント ベースのデータベースがリレーショナル データベースよりも適している典型的な種類のアプリケーションまたはドメインはありますか?

4

7 に答える 7

181

おそらくあなたはすべきではありません:-)

2 番目に明白な答えは、データがリレーショナルでない場合に使用する必要があるというものです。これは通常、データを列のセットとして簡単に説明する方法がないことで明らかになります。良い例は、オフィスの郵便物をスキャンするなどして紙の文書を実際に保存するデータベースです。データはスキャンされた PDF であり、常に存在するいくつかのメタデータ (スキャンされた場所、スキャンされた人、ドキュメントの種類) と、いつか存在する可能性のある多くのメタデータ フィールド (顧客番号、サプライヤー番号、注文番号、ファイルを保持するまで、 ORed フルテキストなど）。通常、今後 2 年以内にどのメタデータ フィールドを追加するかは前もってわかりません。CouchDB のようなものは、リレーショナル データベースよりもその種のデータに適しています。

また、最近ではほとんどすべてのプログラミング言語に含まれている HTTP クライアントを除いて、CouchDB 用のクライアント ライブラリが必要ないという事実も個人的に気に入っています。

おそらく最も明白でない答え: RDBMS を使用することに苦痛を感じない場合は、そのまま使用してください。業務を遂行するために常に RDBMS を回避する必要がある場合は、ドキュメント指向データベースを検討する価値があります。

詳細なリストについては、Richard Jones のこの投稿を確認してください。

于 2009-01-20T22:21:48.427 に答える
47

CouchDB (ウェブサイトから)

  • RESTful JSON API 経由でアクセスできるドキュメント データベース サーバー。一般に、リレーショナル データベースは REST サービスを介して単純にアクセスされるのではなく、はるかに複雑な SQL API を必要とします。多くの場合、これらの API (JDBC、ODBC など) は非常に複雑です。REST は非常に単純です。

  • フラットなアドレス空間でアドホックかつスキーマフリー。リレーショナル データベースには、複雑で固定されたスキーマがあります。テーブル、列、インデックス、シーケンス、ビュー、その他のものを定義します。Couch は、こ​​のレベルの複雑で高価で壊れやすい高度な計画を必要としません。

  • 双方向の競合検出と管理を備えた堅牢な増分レプリケーションを特徴とする分散型。一部の SQL 商用製品はこれを提供します。SQL API と固定スキーマのため、これは複雑で、困難で、費用がかかります。Couch の場合、シンプルで安価に見えます。

  • クエリ可能およびインデックス可能で、Javascript をクエリ言語として使用するテーブル指向のレポート エンジンを備えています。SQL とリレーショナル データベースも同様です。ここには新しいものはありません。

そう。なぜ CouchDB なのか?

  • REST は、JDBC や ODBC よりも単純です。
  • スキーマほど単純なスキーマはありません。
  • シンプルで安価に見える方法で配布されます。
于 2009-01-14T00:36:39.777 に答える
29

他のサーバーデータを愚かに保存して提供するため。

ここ数週間、私は自分のフィード (delicious、flickr、github、twitter など) をポーリングし、couchdb に保存するライフストリーム アプリで遊んでいます。Couchdb の優れた点は、オーバーヘッドなしで元のデータを元の構造のまま維持できることです。ソース サーバーを格納する「クラス」フィールドを各ドキュメントに追加し、ソースごとに JavaScript レンダー クラスを作成しました。

一般化すると、サーバーが別のサーバーと通信するときは常に、スキーマを制御できないため、スキーマのないストレージが最適です。おまけとして、couchdb はサーバーとクライアントのネイティブ プロトコルを使用します。表現には JSON を、転送には HTTP REST を使用します。

于 2009-02-15T09:47:43.040 に答える
22

迅速なアプリケーション開発が思い浮かびます。

スキーマを常に進化させているとき、MySQL/SQLite でスキーマを維持しなければならないことに常に不満を感じています。私はまだ CouchDB をあまり使っていませんが、RAD プロセス中にスキーマを進化させるのがいかに簡単かが気に入っています。

非リレーショナル データベースを使用したくない場合は、多数の多対多の関係がある場合です。特に、結合関係にメタデータが必要な場合は、この種の関係に優れた MapReduce 関数を作成する方法をまだ理解していません。確かではありませんが、CouchDB Map 関数がデータベースに対して独自のクエリを呼び出すことはできないと思います。これは、無限ループが発生する可能性があるためです。

于 2009-01-22T03:13:33.627 に答える
7

レコードごとに同じサイズのフィールドを持つテーブルにデータを格納する必要がない場合は、ドキュメント ベースのデータベースを使用します。代わりに、各レコードを特定の特性を持つドキュメントとして保存する必要があります。最初に「テーブルを変更」する必要なく、任意の長さの任意の数のフィールドをいつでもドキュメントに動的に追加できます。ドキュメントベースのフィールドには、複数のデータを含めることもできます。

于 2010-01-27T02:49:14.703 に答える