2つのテーブル/コレクションがあります。ユーザーとグループ。ユーザーは任意の数のグループのメンバーになることができ、ユーザーは任意の数のグループの所有者になることもできます。リレーショナルデータベースには、UserID列、GroupID列、およびIsOwner列を持つUserGroupsという3番目のテーブルがあります。
私はMongoDBを使用していますが、ドキュメントデータベースにはこの種の関係に対して別のアプローチがあると確信しています。 ObjectIDの2つの配列として、Usersテーブル内にグループと所有者としてのグループのリストを埋め込む必要がありますか?メンバーと所有者のリストをグループテーブルに2つの配列として保存し、関係を効果的にミラーリングして、関係情報の重複を引き起こすべきですか?
または、ブリッジングUserGroupsテーブルは、多対多の関係に対するドキュメントデータベースの正当な概念ですか?
ありがとう
私が見たこと、そして現在使用しているのは、各ドキュメントにノードIDを持つ埋め込み配列です。
したがって、ドキュメントuser1にはプロパティグループがあります:[id1、id2]
また、ドキュメントgroup1にはプロパティユーザー[user1]があります。ドキュメントgroup2には、プロパティユーザー[user1]もあります。
これにより、グループオブジェクトを取得し、関連するすべてのユーザーを簡単に選択できます。ユーザーについても同じです。
これには、オブジェクトの作成および更新時にもう少し作業が必要です。 2つのオブジェクトが関連していると言う場合、両方のオブジェクトを更新する必要があります。
MongoDBにはDBReferencesという概念もあり、ドライバーによっては、ドキュメントを取得するときに参照オブジェクトを自動的にプルします。
http://www.mongodb.org/display/DOCS/Database+References#DatabaseReferences-DBRef
興味のある人のために、mongoDBブログに投稿された非常に良い記事に出会いました。 MongoDBスキーマ設計の6つの経験則 。この記事には3つのパートがあります。3つすべてを読んだ後、十分に理解できます。
例で多対多の関係を理解しましょう
著者への本は少数から少数の関係であるため、他のドキュメント内に一連の本または著者を持つことができます。学生から教師へも同じことが言えます。また、複製のリスクを埋め込むこともできます。ただし、これには、挿入する前に各生徒がシステム内に教師を持っている必要があり、逆も同様です。アプリケーションロジックでは常に許可されない場合があります。つまり、子オブジェクトが存在するには、親オブジェクトが存在する必要があります。
しかし、多対多の関係がある場合は、2つのコレクションを使用して、真のリンクを作成してください。