問題タブ [document-based-database]

.NET または Mono を使用したアクティブな「ドキュメント ベース」のデータベース プロジェクトはありますか? CouchDB、SimpleDB、LotusNotes などに似たもの... オープン ソースを優先します。

JScript.NET テクノロジは、保存された JSON ドキュメントの Map および Reduce 関数に使用できると思います。

私はいくつかのグーグルをしましたが、あまり出てきませんでした。

ユーザーや URL の処理など、Web アプリの一部は RDBMS でうまく機能します。ユーザー、電子メール、ホスト (つまり、stackoverflow.com)、および URL (つまり、https ://stackoverflow.com/questions) を正規化したいと考えています。 /ask ) 1 つの場所で更新すると、すべての場所で更新され、冗長性が最小限に抑えられます。

しかし、私の Web アプリの一部は、Mongo のようなドキュメント ベースのデータベースに非常に適しています。それらには、埋め込みオブジェクトとしてより効率的に機能する多くのコンポーネントがあるからです。

リレーショナル オブジェクトに MySQL を使用し、ドキュメント オブジェクトに Mongo を使用することは理にかなっているでしょうか? それとも、2 種類のデータベースを管理しなければならない手間をかける価値がないのでしょうか? Mongo に参照があることは知っていますが、実際には参照用に設計および最適化されていないことが分かります。

ありがとう！

PS: 私はこれを読みました: MySQL と MongoDB の組み合わせを使用すると、私が求めていることの端をかきましたが、それは実際にはまったく別の質問です。

ドキュメント指向のデータベース (特に RavenDB) には非常に興味をそそられており、少し試してみたいと思っています。しかし、リレーショナル マッピングに慣れている私は、ドキュメント データベースでデータを正しくモデル化する方法を考えていました。

C# アプリケーションに次のエンティティを含む CRM があるとします (不要なプロパティを除外します)。

Company連絡先とタスクには会社以外の目的がなく、ほとんどの場合、タスクまたは連絡先のクエリには関連する会社に関する情報も表示されるため、 これをすべてドキュメントに入れることを考えていました。

問題はTaskエンティティに付属しています。ビジネスでは、タスクが常に会社に関連付けられている必要がありますが、必要に応じてタスクにも関連付けられているとします。

リレーショナル モデルでは、特定のタスクのタスクのみを表示し ながら、TasksテーブルがありCompany.Tasks、会社のすべてのタスクに関連付けられているため、これは簡単です。Contact.Tasks

これをドキュメント データベースでモデル化するために、次の 3 つのアイデアを考えました。

1. タスクを別のドキュメントとしてモデル化します。ほとんどの場合、会社や連絡先を見ると、タスクのリストを見たいと思うので、これは一種のアンチドキュメントデータベースのように思えます。

2. 連絡先に関連付けられていないタスクをリストに保持し、連絡先に関連付けられたCompany.Tasksタスクを個々の連絡先のリストに入れます。これは残念なことに、会社のすべてのタスクを表示したい場合 (おそらく大量になるでしょう)、会社のすべてのタスクと個々の連絡先のすべてのタスクを結合する必要があることを意味します。また、連絡先からタスクを会社に移動する必要があるため、連絡先からタスクの関連付けを解除したい場合、これは複雑だと思います

3. すべてのタスクをCompany.Tasksリストに保持します。各連絡先には、関連付けられているタスクの ID 値のリストがあります。Taskこれは、id 値を手動で取得する必要があり、連絡先のエンティティのサブリストを作成する必要があることを除けば、良いアプローチのようです。

ドキュメント指向データベースでこのデータをモデル化するための推奨される方法は何ですか?

レイヴンは初めてです。Ravenドキュメントにデータを保存するMVCページがあります。期待どおりにすべてのフィールドを保存できます。Id（プロジェクトのテーブル/クラス構造のフィールド/属性）がnullであり、ドキュメントに保存されないことに気づきました。ドキュメントのタイトルにRavenシステムで生成されたIDがあります（DocName / 123など）。DocName / 123または123、あるいはその他の自動生成されたIdフィールドをレイヴンドキュメントに保存するにはどうすればよいですか？助けてください..ありがとう

SQL テーブル tblA と tblB があり、それらの間に 1 対多の関係がある場合.. 複数の raven db ドキュメントを自動的に作成できますか.. Raven DB にドキュメントを自動的にロードできますか... SQL サーバー テーブルから他の方法で...ツールを使用していますか？

私はMongoDbを初めて使用しますが、カプセル化されたデータを保存して高速に取得および更新するために使用することで大きなメリットが得られる既存のアプリケーションがあります。

今私が抱えている問題は、フレームワーク固有の属性や依存関係のない単純な POCO である既存のモデルがあることですが、それらには int である Id フィールドがあります (いくつかは異なりますが、このインスタンスではすべてが int であると仮定する方が簡単です) ）。そのオブジェクトをMongoDbに結び付けることなく（idフィールドの属性を丸めたり、タイプをObjectIdフィールドに変更したり）、外部構成を介してidフィールドを自動的に取得する方法はありますか?

それが世界の終わりでない場合は、Nhibernate の場合と同様に、MongoDb の目的でマッピングされるドメイン オブジェクトを作成します。Id フィールドが異なるだけで、同じクラスの 2 つのバージョンを用意する必要はありません。この場合のように、ドメインは同一になります。

この質問は必ずしも Couchbase 2.0 開発プレビュー固有のものではありませんが、新しい Couchbase 製品を調査する際に役立つと思います。

データモデリングに関するアドバイスを探しています。リアルタイム分析に使用できる可能性があるため、Couchbase を調査しています。

ただし、実世界のデータをモデル化する最善の方法に関するドキュメントは見つかりません。

シナリオを提案します。コミュニティが私を助けたり、これをモデル化する方法についていくつかのアイデアを議論したりできる場合、それは非常に役立ちますか?

これは私たちの製品を代表するものではなく、私たちに代わってモデリングを解決するよう人々に求めているわけではないことに注意してください。

顧客が特定の日時に製品を購入し、製品には ID、名前、説明、価格などの情報があり、購入が日付に行われると仮定します。

最初の要件は、2 つの日付間のすべての購入をカウントできることです。1 日で 100,000 を超える購入があるかもしれません - これはかなり大きなビジネスです ;)

構文のいずれかが正しくない場合はお知らせください。すべてのアドバイス/ヘルプを歓迎します。

データを次のようにモデル化した場合 (完全に間違っている可能性があります):

商品と一緒に購入

このドキュメント レイアウトでは、各購入を確認でき、その購入に含まれていた製品を確認できますが、2 つの日付間のすべての購入をカウントするにはどうすればよいでしょうか? また、2 つの日付間のすべての購入のログを日付の降順で表示するにはどうすればよいでしょうか?

これはCouchbaseが適しているものですか?

2 つの日付の間に何十万もの購入があるかもしれませんが、顧客はレポートを待ちたがりません….誰もが経験していると思います ;)

incr 関数を使用するのが最善でしょうか? その場合、どのようにデータをモデル化しますか?

これを読んでくれた人に感謝します。可能であれば、現実世界のモデリングの問題の例をさらに詳しく説明したいと思います。

ジェームズ

データ ストアで一連のレコード/ドキュメントを実行できるようにしたいのですが、それらのレコードを常に RAM に最新の状態で保持したいと考えています。約 1.5GB から 2GB の RAM を使用するだけで済みます (潜在的にはそれ以下)。これは、組み込みではなくサーバーベースになります。

豊富なクエリ機能が必要なため、メモリ内のキーと値のストアが機能しないことはわかっています。

MySQL がメモリベースのテーブルを実行できることは知っていますが、私が考えていることに人々がこの機能を使用するかどうかはわかりません。SQL Server はテーブルをメモリに固定できますか? テーブル全体？

他にどのようなデータ ストアを確認する必要がありますか? Map/Reduce スタイルのクエリも、高速であれば問題ありません。

リレーショナル データを MongoDB に保存する必要がありますか?

私のユニークな状況（以下に概説）を考えると、どんな洞察も大歓迎です!! 他のプロジェクトと同様に、私のリソースは非常に限られています。できるだけ低コストでパフォーマンスを向上させたいと考えています。:)

バックグラウンド

1. 拡張的で複雑なデータ モデルを使用するプロジェクトに取り組んでいます。
   1. 84 のプライマリ テーブル
   2. セカンダリ テーブルへの 44 のビュー
   3. メイン項目タイプの 600k インスタンス
   4. 600k のメイン項目をサポートする 500,000,000 以上のタプル
2. モデルは適切に正規化されており、よく考えられています。
3. 多くのアイテムは、パフォーマンスのために非正規化されています。
4. 私たちのデータ アクセス レイヤーは、ORM に Hibernate を使用します。

問題文

Hibernate は、84 個のテーブルと 44 個のビューを結合して、プライマリ データ項目を一緒にマップします (プライマリ データ項目を THEObject と呼びます)。この構成は非常にコストがかかります (単一の Oracle db ノード)。THEObject とその子を組み立てるのに数分かかる場合があります。

THEObject のインスタンス間で共有されるデータはほとんどありません。共有されるデータは、主に読み取り専用です (ユーザー データ、一般的な構成への参照など)。

THEObject の保存も非常にコストがかかります。

サイド プロジェクトとして、THEObject のデータを表す一連の Bean を作成し、THEObject の高価なインスタンスからデータを Bean にコピーし、xstream を使用して Bean を XML にシリアル化しました。THEObject から Bean への変換、Bean のシリアル化、および Bean を表す XML の保存にかかった時間は、わずか 26 ミリ秒でした。(リレーショナル表現で休止状態を使用して THEObject を保存するのに必要な 6 分にはほど遠い)。うーん

私が使用するデータには 3 つの主要なチャンク タイプ (コレクションを考える) があり、THEObject を表すチャンクは他の 2 つの主要なチャンクからのデータを共有しますが、共有しないため、アプリケーションはドキュメント ベースのデータベースによってより適切に処理されると思います。 THEObject の他のインスタンスの中にある独自のデータ。これにより、正規化されたストレージに関連する結合やパフォーマンスの低下なしに、アイテム全体として THEObject を読み取ることができます。

実際にはリレーショナル データであるにもかかわらず、ドキュメント ベースのデータベースにデータを格納することは合理的でしょうか?!

関連する読書

リレーショナル データベースの代わりにドキュメント ベースのデータベースを使用する必要があるのはなぜですか?

非リレーショナル データベース設計

MongoDB と Cassandra の比較

NoSQL とは何ですか?どのように機能し、どのような利点がありますか?