私は MySQL のバックグラウンドを持っており、ドキュメント指向のデータベース、特に CouchDB に興味があります。私が興味を持っていることの 1 つは、データの整合性です。ドキュメント指向データベースはこれをどのように処理しますか? たとえば、RDBMS では、レコードの重複を防ぐ方法や、1 ビットの情報がある場合は別の情報があることを保証する方法、またはまったく情報がないことを保証する方法があります。
より大まかに言えば、私の質問は、DODBes が使用される問題と比較して、RDBMS はどのようなタイプの問題に対して切り捨てられるのでしょうか? 説明のために他のスタックオーバーフローの質問をいくつか調べましたが、良い質問は見つかりませんでした。
また、作業中のデータベースを使用して、値の合計と平均、および履歴トレンドを使用して、多くのレポートを作成しています。これはドキュメント指向のデータベースに適していますか?
ほとんどのドキュメントデータベースは、非常に限られた整合性しかサポートしていないか、整合性チェックをサポートしていません。彼らは、データが正しいことを確認するためにアプリケーションに依存しています。CouchDBでどのようになっているのかをお伝えできます。
第二部へ。RDBMSは、データのレポートと分析に非常に優れていると思います。結合、集計、関数などを使用してデータに対して複雑なクエリを実行できるという事実により、RDBMSは非常に強力なレポートツールになります。ドキュメントデータベースは、「ライブ」アプリケーションデータを保存するのに非常に適しています。リトリーブオブジェクトグラフをドキュメントデータベースに保存するのは非常に簡単です。スキーマフリーの設計により、新しいアプリケーション機能のためにモデルを簡単に拡張できます。ただし、これは、アプリケーションデータを適切なドキュメントに分割できる場合にのみ機能します。そうでなければ、あなたは優雅さの多くを失います。
主にレポートを作成したい場合は、RDBMSをお勧めします。フラットでシンプルなレコードをたくさん保存する場合、レポートを作成するのは非常に簡単です。工具などはレポートに最適です。ただし、複雑な構造化データのレポートを作成する場合は、RDBMSよりも別のデータベース設計を使用した方がよいでしょう。
ただし、これは、RDBMSに制限する必要があるという意味ではありません。2つのテクノロジーを組み合わせることができます。ブログソフトウェアを想像してみてください。ブログ投稿やコメントなどの「ライブ」アプリケーションデータをドキュメントデータベースに保存します。クリック統計やログイン統計などのレポート用のデータは、RDBMSに保存されます。RobConerysの投稿も参照してください。