問題タブ [document-database]

ドキュメント指向データベースを使用して次のシナリオを解決する方法を教えてください。

'Page1' (バージョン V1.0) というページは、ドキュメント 'Document1'、'Document2'、および 'Document3' のコンテンツ ページにすることができます。「Page1」のコンテンツを編集した場合 (バージョンを V1.0 から V1.1 に変更する必要があります) この変更は「Document1」と「Document2」にのみ反映され、「Document3」には影響しないはずです。

現在、ドキュメント 'Document1' と 'Document2' は 'Page1' - バージョン V1.1 を参照しています。しかし、ドキュメント 'Document3' はまだ 'Page1' - バージョン V1.0 を参照しています。

このように、すべてのページの変更/バージョンを追跡する必要があります。

これらの変更を追跡するには、リレーショナル データベースよりも NoSQL データベースの方が非常に便利です。では、ドキュメント指向のデータベースで、このシナリオを解決するのはどれでしょうか?

RavenDb に次のドキュメントがあるとします。

そして、次のビューモデル:

データベースに何度もアクセスしたり、構造を手動で収集/構築したりせずに、そのビューモデルを構築する最良の方法は何でしょうか?

これにマルチマップを使用できますか？

ばかげた質問かもしれませんが、RavenDb をしばらく使用していません。Android / iPhone dev をやっていたのでちょっとさびました！

CouchDB の優れた点は、データベースの変更に応じてビューの結果が段階的に更新されることです。MongoDB で同じことを達成する方法はありますか? ドキュメントで詳細を見つけることができませんでした。ありがとう

自由形式の構造を持つドキュメントは、(リレーショナル データベースとは対照的に) データの保存に適している場合があります。しかし、ドキュメント全体をディスクに再書き込みする必要があるため、データに小さな変更を加えることと組み合わせて保持するという問題が 1 つあります。

だから私の質問は、「文書データベース」はこれを解決するために特別に作られたものですか?

アップデート

「ドキュメント指向データベース」の概念がよく理解できたと思います。明らかに、いかなる種類のドキュメントでもありませんが、各実装では、JSON などの独自の形式が使用されます。そして、私の質問に対する答えも明らかになります。変更のたびに JSON 構造全体をディスクに書き直して永続化する必要があるとしたら、それはあまり優れたデータベースとは言えません。

mongodb でファイルを保存および取得するにはどうすればよいですか? 使ってみました

私は NoSql データベースを初めて使用し、ローカル ドライブで 20 MB を超える可能性のある非常に大きな JSON ドキュメントを処理する方法を理解するのに苦労しています。この構造は時間の経過とともに間違いなく増加し、クエリの速度と、文字列を取得するためだけに返された JSON オブジェクトのネストを深く検索する必要があることを心配しています。たとえば、私のJSONは深くネストされています。

メイン アプリケーションでは、試験の種類、年、科目に基づいて質問オブジェクトが作成および追加されるため、時間の経過とともに JSON ドキュメントが巨大になります。将来的に遅いクエリを回避するために、これを再モデル化するにはどうすればよいですか?