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