名前、パスワード、電子メールなどのコレクションを持っています。
また、私はコレクションを持っていますグループ、すべてのグループはメンバーです。
データベースをどのように設計すればよいですか？
ウェイ1（MySQLのような）：すべてのユーザーは_idを持っているので、メンバーの配列に入れるだけです。
方法2：ユーザー文書全体をコピーし、いくつかのフィールドを追加します。
MongoDBサイトでは、重複したデータは安価なストレージの安価なものではないと言っています。また、彼らは、データの読み込みにJOINを避けるべきだと言います。私のMongoデータベースを設計するには
実際にこの質問に対する回答は、デザインしている画面の種類と、データを取得するためにどのような種類のクエリを行うかによって異なります。各オプションの秤量に役立つ各オプションの長所と短所を説明します。
ウェイ1： - グループのコレクションにuser_idsの配列を置く
賛否
1）あなたはすべてのメンバーの特定のグループやリストのグループの詳細（users_idsを表示する画面を持っている場合）を使用すると、1つのクエリでこの画面に必要なすべての詳細を取得できますが、これも高速です。
短所
1）グループの詳細画面では、あなたが別のクエリでは、ユーザーの詳細を取得することになる、MongoDBのは、いずれかの加入提供していない、それ以来、グループの詳細と一緒にユーザーの詳細を表示する必要がある場合クライアント側の両方に参加しています。これはパフォーマンスに影響を与える可能性があります。
2）ユーザーの詳細と所属するすべてのグループを表示する画面がある場合、グループコレクションのユーザーアレイでuser_idを検索します。グループ内のメンバーの数が非常に多い（数百万人）と予想される場合は、アレイ内を検索するとパフォーマンスに大きな影響を与える可能性があります。
ウェイ2： - データの複製グループコレクション
内部の内部コピーのユーザードキュメントは、MongoDBのに問題はありませんが、あなたはそのための本当に良い理由があるはずです。関係が1の場合、Thumbルールは重複データである必要があります。
賛否
1）1つのクエリはそのユーザーと一緒にグループのすべての詳細を取得することができますので、このアプローチは、クライアント側でグループおよびユーザーのコレクションに参加するからあなたを救うでしょう。あなたはuser_id_1に更新があるとき
短所が
1）あなたは百万基を有し、user_id_1 100,000のグループに属していると仮定し、それから、あなた100,000文書を更新する必要があります。これは、パフォーマンスに大きな影響を与える可能性があります。
2）また、多数のユーザーが1つのグループを購読する場合、このグループの文書サイズは増加し続けます。 Mongodb The maximum BSON document size is 16 megabytesでは、16MBを超える文書は作成できないため、ユーザーを無限にグループに追加することはできません。これにより、機能が制限されます。
ウェイ3： - 埋め込みグループの詳細ユーザーコレクションで
賛否
1）一つのクエリは、このユーザーが属するすべてのグループのすべての詳細と共に、ユーザの詳細情報を取得することができます。
2）グループ内にごく少数のユーザーがいると思われる場合は、ユーザー文書にグループアレイがほとんどありません。これは16MBの制限を超えません。
短所
1）あなたは、ユーザーが多く、多くのグループ（百万人）に加入できることを期待している場合、ユーザーのドキュメントには、16メガバイトの制限を超える場合があります。
2）また、グループの詳細情報が頻繁に更新されている場合は、多くのユーザー文書で更新する必要があります。
ます。また、データモデル設計の詳細を取得するには、以下のリンクから行くことができます： - https://docs.mongodb.org/manual/core/data-model-design/
これは、アプリケーションでのデータの使用方法によって異なります。
グループが3つ以上あり、すべてのグループでユーザーを検索する必要がある場合は、ユーザー文書をグループ（方法2）に埋め込むことはお勧めできません。したがって、この場合には、私は推測その後、2
方法を使用して、クエリを実行するときにのみ、2グループまたはユーザー・グループは、アプリケーションの前に知られているであろうお持ちの場合1.
方法を使用することをsugestユーザーデータを直接更新、取得、削除するほうがよいので、データを分離することが最善の方法です。
重複データを約
このを心配することは何もありません、それは更新に来るときについてを心配するものです。すべての文書にネストされ、複製されたユーザーの詳細があるとします。ユーザーが名前を変更するとどうなりますか？すべてのドキュメントで、そのユーザーのすべてのインスタンスを更新する必要があります。
データとエンティティを区別するように注意してください。ユーザーはエンティティであり、エンティティを複製する前に慎重に考える必要があります。
個人的には、パフォーマンスがあまりにも遅すぎてリアルタイムで参加できない状況になっていない限り、私はそれらを分割します。そして、その時だけ、マージを検討してください。