OK、これを基本的な「品種」に分解する必要があると思います。
2つの「エンティティ」スタイルのオブジェクトがあります：
UserCampaign
「マッピング」スタイルのオブジェクトが1つあります：
-
UserCampaign
「トランザクション」スタイルのオブジェクトが1つあります：
Click
ステップ1：エンティティ
簡単なものから始めましょう：User ＆Campaign 。これらは本当に2つの別個のオブジェクトであり、どちらも実際にはその存在を他方に依存していません。また、2つの間に暗黙の階層はありません。ユーザーはキャンペーンに属しておらず、キャンペーンもユーザーに属していません。
このようなトップレベルのオブジェクトが2つある場合、通常、それらは独自のコレクションを獲得します。したがって、Userが必要になります コレクションとCamapaigns コレクション。
ステップ2：マッピング
UserCampaign 現在、NからMへのマッピングを表すために使用されています。さて、一般的に、Nから1へのマッピングがある場合、Nを1の内側に置くことができます。ただし、NからMへのマッピングでは、通常、「サイドを選択」する必要があります。
理論的には、次のいずれかを実行できます。
Campaign IDのリストを入力してください ■各Userの内部Users IDのリストを作成します ■各Campaignの内部
個人的には、＃1を行います。おそらく、キャンペーンを行うユーザーの数がはるかに多く、アレイを短くする場所に配置したいと思うでしょう。
ステップ3：トランザクション
クリックは本当に完全に異なる獣です。オブジェクトの用語では、次のように考えることができます：Click Userに「所属」 、Click Campaignに「所属」 。したがって、理論的には、クリックを保存するだけで、これらのオブジェクトのいずれかの一部になります。クリックは下に属すると考えるのは簡単です。 ユーザーまたはキャンペーン。
しかし、あなたが本当に深く掘り下げるならば、上記の単純化は本当に欠陥があります。システムで、Click 本当に中心的なオブジェクトです。実際、ユーザーとキャンペーンは実際にはクリックに「関連付けられている」とさえ言えるかもしれません。
あなたが尋ねている質問/質問を見てください。これらの質問はすべて、実際にはクリックを中心にしています。 ユーザーとキャンペーンはデータの中心的なオブジェクトではなく、クリック数は中心的なオブジェクトです。
さらに、クリック数はシステムで最も豊富なデータになります。何よりもクリック数が多くなります。
これは、このようなデータのスキーマを設計する際の最大の問題です。 「親」オブジェクトが最も重要でない場合は、それらをプッシュする必要がある場合があります。単純なeコマースシステムを構築することを想像してみてください。 ordersは明らかです Userに「所属」します 、ただしorders システムの中心であるため、「トップレベル」のオブジェクトになります。
まとめ
おそらく3つのコレクションが必要になります：
- ユーザー->キャンペーンのリストがあります。_id
- キャンペーン
- クリック->にはuser._id、campaign._idが含まれます
これにより、クエリのニーズがすべて満たされるはずです：
IP、リファラー、OSなどの各クリックからの情報を参照してください
db.clicks.find()
X IP、Xリファラー、XOSからのクリックの頻度を確認する
db.clicks.group() またはMap-Reduceを実行します。
各クリックをユーザーとキャンペーンに関連付けます
db.clicks.find({user_id : blah}) クリックIDをユーザーとキャンペーンの両方にプッシュすることも可能です（それが理にかなっている場合）。
クリック数が多い場合は、最も実行するクエリを実際に分析する必要があることに注意してください。すべてのフィールドにインデックスを付けることはできないため、Map-Reducesを実行して、これらのクエリのデータを「ロールアップ」することをお勧めします。