問題タブ [document-database]

私は、ドキュメントベースのデータベース（この場合はCouchDB）でいくつかの要件を達成できるかどうかを確認しようとしてきました。2つの一般的な要件：

• 一意のインデックスを持ついくつかのフィールドを持つエンティティのCRUD
• eBayのようなeコマースウェブアプリ（より良い説明はここにあります）。

そして私は、ドキュメントベースのデータベースがこれらの要件に対処するための最良の選択ではないと考え始めています。さらに、ドキュメントベースのデータベースの使用を想像することはできません（おそらく私の想像力はあまりにも限られています）。

これらの要件にドキュメント指向データベースを使用しようとしたときに、ニレに梨を求めているかどうかを説明してもらえますか？

Web サイトの作成を検討しており、オブジェクト データベースまたはドキュメント データベースのいずれかを学びたいと考えています。ホスティング プロバイダーを使用する予定なので、ソフトウェアをインストールすることはできません。ライセンスを購入できないので、無料またはオープン ソースのオブジェクト/ドキュメント データベースを使用できるようにする必要があります。なんらかのインストールを必要としない無料のオブジェクト/ドキュメント データベースはありますか?

リレーションとドキュメント データベースについて議論している投稿はかなりありますが、それらはすべて非常に一般的なものです。

特定の例でそれらの違いを理解したいと思います。

別のスクラム指向のプロジェクト管理 Web アプリを構築しているとしましょう。

私たちは新しいテクノロジーを試してみたいと思っていますが、デザインを犠牲にして全体的な複雑さを増やして誇大宣伝されている新しいことをしたくありません. たとえそれが古い技術を使用することを意味するとしても、私たちは正しい決定を下したいと考えています。

したがって、PivotalTrackerについて考えてみてください。プロジェクト、ストーリー、ストーリー コメント、まれな添付ファイル、サブタスク (実際のタスクに分割されたストーリー) を保存します。

反復もサポートされているため、各タスクは実際にはプロジェクトに属し、反復することができます。反復内では、タスクを特定の順序で配置する必要があります。ユーザーはストーリーを上下にドラッグして並べ替えることができます。

ストーリーごとに、別の時間エントリを使用して、それに費やされた時間を追跡したいと考えています。

レポートを生成したいかもしれませんが、あまり派手なものはありません (バーンダウン、おそらく時間に関連するもの)

リレーショナルとドキュメントのどちらの DB を使用しますか? それとも他の？なぜ？

その構造をどのように設計しますか？たとえば、ドキュメント DB を使用する場合、正規化しますか?

リレーショナルデータベースではなく、ドキュメント/オブジェクトデータベースを使用することでメリットが得られる.Netプロジェクトがいくつかあります。db4oは良い選択だと思いますが、いくらかかるかはわかりません。MongoDBを使用したいのですが、その設計は小規模な単一サーバーアプリケーション向けではありません。

小規模なアプリケーションで遭遇したことのない他のオプションはありますか？

編集：それで、これはまだ良い解決策を持っていないスペースですか？小規模で耐久性のあるドキュメントデータベースはありませんか？私の最善の選択は、MongoDBを使用し、-syncdelayオプションを1に設定することですか？

ポートでリッスンしている DB4O サーバーがあります

コールバックに登録するにはどうすればよいですか? たとえば、オブジェクトを読み取ったり保存したりする前にカスタム コードを実行するにはどうすればよいでしょうか。

RavenDBなどのドキュメントデータベースが非リレーショナルであるとすると、複数のドキュメントに共通するデータの重複をどのように回避しますか？複製しても問題がない場合、そのデータをどのように維持しますか？

私はドキュメントデータベース、特にRavenDbを調べてきましたが、すべての例は明確で理解しやすいものです。与えられた構造がいくつのレベルを持っているかを前もって知らない例を見つけることができません。例として、次のクラスが与えられた場合、どのように家系図を永続化しますか？

私が見たほとんどの例では、集約ルートを検索してドキュメントにします。ここでは、集約ルートと境界が何であるかはそれほど明白ではありません。

現在、schema.xml ファイルを構成しており、ドキュメントをセットアップする最善の方法を見つけようとしています。私は RMDBS を使用しているため、多くのオブジェクトはリレーショナルです。

たとえば、このサイトを見てください。ドキュメントは通常、質問とそれに続く 0 個以上の回答で構成されます。このためにフィールドを設定したいとします。私が見ているように、すべての質問フィールドと回答フィールドを同じドキュメントで宣言する必要があります。ただし、複数の回答が存在する可能性があるため、回答ごとにドキュメントを作成する必要があります。つまり、各質問と各回答は、両方のフィールドを含む個別のドキュメントに保存されます。

この種の問題に対する別のアプローチは見当たりませんが、Solr とドキュメント DB には比較的慣れていないため、間違っている可能性があります。

要するに、そのようなスキーマを実装する場合のベスト プラクティスは何ですか?

RavenDB を使用するために、既存の Web アプリケーションを移行しようとしています。

現在、私の Web アプリケーションには、クエリ文字列の ID に基づいてカテゴリ、サブカテゴリ、およびリソースを表示できるページがあります。

ただし、RavenDB は集約ルートの ID を生成しますが、子エンティティの ID は生成しないことに気付きました。

サブカテゴリは集約ルート (カテゴリにはサブカテゴリがあります) ではないと思うので、カテゴリ ドキュメントのサブドキュメントにしています。

クエリ文字列で渡された ID で直接アクセスしているため、サブドキュメントにするのは間違っていますか? しかし、そうでない場合、RavenDB は集約ルートではないエンティティの ID を生成しないように見えるため、個々のサブカテゴリにアクセスするにはどうすればよいですか?