OK, ich denke, Sie müssen das in die grundlegenden "Sorten" aufteilen.
Sie haben zwei Objekte im "Entity"-Stil:
User
Campaign
Sie haben ein Objekt im "Mapping"-Stil:
UserCampaign
Sie haben ein Objekt im "transaktionalen" Stil:
Click
Schritt 1:Entität
Beginnen wir mit den einfachen:User
&Campaign
. Dies sind wirklich zwei getrennte Objekte, keines hängt in seiner Existenz wirklich vom anderen ab. Es gibt auch keine implizite Hierarchie zwischen den beiden:Benutzer gehören weder Kampagnen noch Kampagnen gehören Benutzern.
Wenn Sie zwei solche Top-Level-Objekte haben, verdienen sie im Allgemeinen ihre eigene Sammlung. Sie brauchen also einen User
Sammlung und eine Campaign
Sammlung.
Schritt 2:Zuordnung
UserCampaign
wird derzeit verwendet, um eine N-zu-M-Abbildung darzustellen. Wenn Sie nun eine N-zu-1-Zuordnung haben, können Sie das N im Allgemeinen in die 1 einfügen. Bei der N-zu-M-Zuordnung müssen Sie jedoch im Allgemeinen "eine Seite auswählen".
Theoretisch könnten Sie Folgendes tun:
- Hinzufügen einer Liste mit
Campaign ID
s in jedemUser
- Fügen Sie eine Liste mit
Users ID
ein s innerhalb jederCampaign
Ich persönlich würde #1 machen. Wahrscheinlich haben Sie viel mehr Benutzer, die Kampagnen durchführen, und Sie möchten das Array wahrscheinlich dort platzieren, wo es kürzer ist.
Schritt 3:transaktional
Klicks ist wirklich ein ganz anderes Biest. Sachlich könnte man Folgendes denken:Clicks
einem User
"gehören". , Clicks
"gehören zu" einer Campaign
. Theoretisch könnten Sie also einfach speichern, dass Klicks Teil eines dieser Objekte sind. Es ist leicht zu glauben, dass Klicks unter gehören Benutzer oder Kampagnen.
Aber wenn Sie wirklich tiefer graben, ist die obige Vereinfachung wirklich fehlerhaft. In Ihrem System Clicks
sind wirklich ein zentrales Objekt. Vielleicht können Sie sogar sagen, dass Nutzer und Kampagnen wirklich nur mit dem Klick „verbunden“ sind.
Sehen Sie sich die Fragen / Abfragen an, die Sie stellen. All diese Fragen drehen sich eigentlich um Klicks. Nutzer und Kampagnen sind nicht das zentrale Objekt in Ihren Daten, sondern Klicks.
Darüber hinaus sind Klicks die am häufigsten vorkommenden Daten in Ihrem System. Sie werden viel mehr Klicks haben als alles andere.
Dies ist das größte Problem beim Entwerfen eines Schemas für solche Daten. Manchmal müssen Sie "übergeordnete" Objekte abschieben, wenn sie nicht das Wichtigste sind. Stellen Sie sich vor, Sie bauen ein einfaches E-Commerce-System. Es ist klar, dass orders
würde users
"gehören". , aber orders
ist so zentral für das System, dass es ein "oberstes" Objekt sein wird.
Abschließen
Wahrscheinlich möchten Sie drei Sammlungen:
- Benutzer -> hat eine Liste von campaign._id
- Kampagne
- Klicks -> enthält user._id, campaign._id
Dies sollte alle Ihre Abfrageanforderungen erfüllen:
Sehen Sie sich die Informationen von jedem Klick an, wie IP, Referer, Betriebssystem usw.
db.clicks.find()
Sehen Sie, wie oft Klicks von X IP, X Referrer, X OS kommen
db.clicks.group()
oder führen Sie ein Map-Reduce durch.
Verknüpfen Sie jeden Klick mit einem Nutzer und einer Kampagne
db.clicks.find({user_id : blah})
Es ist auch möglich, Klick-IDs sowohl in Benutzer als auch in Kampagnen zu übertragen (sofern dies sinnvoll ist).
Bitte beachten Sie, dass Sie bei sehr vielen Klicks wirklich die Abfragen analysieren müssen, die Sie am häufigsten ausführen. Sie können nicht jedes Feld indizieren, daher möchten Sie oft Map-Reduces ausführen, um die Daten für diese Abfragen "zusammenzufassen".