2

こんにちは私はmongodbの初心者です。Javaを使用しています。

リレーショナルテーブルにTenant、system、authorizationの4つのテーブルがあります。

このようなもの。

Table            Fields

Tenant           Tenant_ID(PK), Tenant_INFO
System           System_ID(PK), System_Info
Authorization    System_ID, Autho_Info.
System_prop      System_ID, Prop_Info, Tenant_ID

System_propテーブルでは、Tenant_IDはテナントテーブルTenant_ID（PK）を参照し、System_IDはシステムテーブルSystem_IDを参照します。

承認テーブルでは、System_IDはシステムテーブルSystem_IDを参照します

データベースをリレーショナルからmongodbに切り替えています。私が最初にする必要があるのはスキーマ設計です。

私がする必要があるクエリは次のとおりです。

  1. SELECT A.Prop_Info、A.System_ID From System_prop A、SYSTEM B、TENANT Cここで、A.System_ID = B.System_ID AND A.Tenant_ID = C.Tenant_ID

  2. SELECT A.System_ID、A.Prop_Info FROM Authoization A、SYSTEM B WHERE A.System_ID = B.System_ID

これらのテーブルをmongodbのコレクションとして設計する方法を教えてもらえますか？

dbrefを使用して埋め込む必要がありますか？このためのスキーマの設計を手伝ってください。

4

3 に答える 3

2

Prop_Infoあなたの挑戦は、両方のクエリによって取得されなければならないという事実から来ています。これにより、どのMongoコレクションに配置する必要があるかを判断するのが困難になります。

MongoDBでは、クエリパターンに必要なすべての情報を単一のドキュメントに含めるという理想的な目標を持って、ドキュメントスキーマを作成します。2つの別々のコレクションに対して2つの別々のクエリによって返される同じデータD（あなたの場合など）が必要な場合は、次の3つの戦略から選択する必要があります。Prop_InfoAB

  1. とDの両方のドキュメントを複製し、コードとの一貫性を確保します。これは通常、挿入/更新側でコードがさらに複雑になり、MongoはACIDではないため、一貫性の問題が発生する可能性がある場合でも、2番目のクエリの必要性を排除したい高性能システムの設計上の選択です。AB

  2. 2番目のクエリで参照できるように、参照（ DBRefまたは識別フィールドの他の組み合わせ）を入力して保存しDます。これは通常、クエリの数がへのクエリの数を超える場合の設計上の選択です。これは、より頻繁にクエリされるコレクションのローカルを維持します。このスキーマデザインパターンでは、クエリを実行するときに2番目のクエリを実行するだけで済みます。ABABDB

  3. 新しいDコレクションを入力し、とCの両方からコレクションに2番目のクエリを作成します。これは通常、上記の（1）または（2）を使用した場合のトレードオフが明確でない、非常に不確実な将来の要件に直面した場合の設計上の選択です。これは最も「リレーショナルに似た」スキーマであり、との両方をクエリするときに2番目のクエリを実行するように強制するスキーマです。ABAB

どの戦略を選択するかは、ドメイン、クエリパターン、オブジェクトリレーショナルマッピング（ORM）フレームワーク（使用する場合）から得られるサポート、そして最後になりますが、好みによって異なります。

私が遭遇した状況では、私は決して選択しませんでした（3）。私は（1）を高性能な状況（分析システム）で使用しました。クエリアクセスパターンによって「共有」データが存在する場所が明確になったため、他のすべての場所で（2）を使用しました。

戦略を選択した後も支援が必要な場合は、選択した戦略に基づいてスキーマ設計の問題に特に焦点を当てた別のSO質問を投稿してください。

最後の3つのヒント：

  1. 共有データDの関係の多重度が1より大きい場合は、配列を使用します。配列全体にインデックスを付けたり、を使用して配列内を正確にクエリしたりできます$elemMatch。

  2. Dストラテジー（1）または（2）で更新するには、MongoDBのアトミック修飾子操作を使用します。これらの操作の多くは配列で動作するように設計されています。

  3. このSOの質問は、@Stennieの回答のDBRef2クエリパターンを対象としています。（@Stennieは、MongoDBのマーカーである10genで動作します。）

幸運を！

于 2012-09-02T23:55:41.523 に答える
2

すべてのドキュメントを含む1つのコレクションだけが必要な場合もあります。もちろん、繰り返しフィールドが多すぎることになりますが、これは適切にスケーリングするための秘訣です。Relationsの場合、タイプ1対多および1対1の場合、MongoDBが主キーを処理するため、識別子を削除して残りの属性を配置するだけです。（「そのためにMongoDBが大好きです」）。

テナントとシステムの間にある多対多の関係では、MongoDBデータ構造の配列に変更する必要があります。

coll{
Tenant : 'value',
tenant_info : 'value',
Sys_info: 'value' ,
auth_info: 'value' ,
Prop_info : array [ 'value','value',''value....]
}
于 2012-09-03T01:11:52.970 に答える
1

あなたはまだリレーショナルデータベースで考えています。ただし、MongoDBはドキュメント指向のデータベースです。

  1. すべてのドキュメントにはGUIDである_idフィールドが自動的にあるため（グローバル一意であることが保証されているのと同じくらい良い）、通常、人工ID番号は必要ありません。
  2. リレーションテーブルはMongoDBでは使用しないでください。n型の関係は、代わりに配列フィールドを使用して作成されます。したがって、1つのシステムにN個の権限がある場合、システムドキュメントには、そのシステムが持つ権限のオブジェクトIDの配列である「権限」フィールドが必要です。はい、それはリレーショナルデータベースの正規化ルールの恐ろしい違反になります。しかし、ここにはリレーショナルデータベースがありません。MongoDBでは、配列はクエリ言語に対して透過的であるため、配列でN関係を表すのが実用的です。
于 2012-09-02T23:22:02.603 に答える