私は noSQL データベース (MongoDB) を初めて使用し、コレクションを整理する方法がわかりません。私はすべてのユーザーが持っているユーザーシステムを持っています:
- _id
- ユーザー名
- パスワード
- ... (より基本的なデータ)
- 友達
- 評判ポイント
- 評判ポイントの歴史
- 通知
- 参加しているユーザーグループ
基本的なデータは通常コレクションユーザーに格納されますが、友人のリストのような複雑なデータを格納する方法がわかりません。
すべてのユーザー オブジェクト (ユーザー コレクション内)に _idの配列のように友達を保存する必要がありますか?それとも新しいコレクションを作成して友達だけを保存する必要がありますか? この新しいコレクションを作成すると、ユーザーの _id とその友人の配列、または user => friend _id のようなペアになるはずです。
通知と履歴についても同様です。友人と同じ問題を抱えていますが、これらの場合の配列のサイズははるかに大きくなる可能性があるため、新しいコレクションを使用するという考えはより強力です。
各ユーザーの友達が他のユーザーであるようなソーシャルネットワークを作っていると思います。
通常、MongoDBでは、ドキュメント間の関係のみを表すコレクションは避ける必要があります。リレーショナルデータベースでは、これらを使用してテーブルを結合しますが、MongoDBは結合をサポートしていません。
各ユーザーに友達の配列を追加する必要があります。これは、MongoDBで多対多の関係を実装する通常の方法です。ただし、アグリゲーションではなくリレーションがあるため（フレンドはユーザーによって所有されておらず、独立して存在します）、フレンドオブジェクト全体をこれらの配列に配置しないでください。その代わりに、ユーザーコレクション内の友達を見つけるために使用できる一意の識別子を使用する必要があります。これは、フレンドの_id、DBRef、またはフレンドの名前のいずれかになります（これらが一意でインデックスが作成されている場合のみ）。後者のソリューションでは、参照されているすべてのドキュメントを要求することなく、ユーザーの友達の読み取り可能なリストを取得できます。
オブジェクト全体をユーザードキュメントに保存することが理にかなっている反例は、通知である可能性があります。通知は個々のユーザーに送信されます。ユーザーがいなければ、通知は無意味です。通知を受信しているユーザーがいなければ、通知は必要ありません。ユーザーが削除されると、その通知も一緒に削除できます。したがって、ユーザードキュメントに直接保存できます。