Hoe moet ik dit schema in MongoDB implementeren?

OK, ik denk dat je dit moet uitsplitsen in de basis "variëteiten".

U hebt twee objecten in de stijl van een "entiteit":

• User
• Campaign

Je hebt één object in "mapping"-stijl:

• UserCampaign

U heeft één object in "transactionele" stijl:

• Click

Stap 1:entiteit

Laten we beginnen met de makkelijke:User &Campaign . Dit zijn echt twee afzonderlijke objecten, geen van beide is voor zijn bestaan ​​​​echt van de ander afhankelijk. Er is ook geen impliciete hiërarchie tussen de twee:gebruikers horen niet bij campagnes en campagnes horen ook niet bij gebruikers.

Als je twee van dit soort objecten op het hoogste niveau hebt, verdienen ze over het algemeen hun eigen verzameling. U wilt dus een Users collectie en een Camapaigns collectie.

Stap 2:in kaart brengen

UserCampaign wordt momenteel gebruikt om een ​​N-naar-M-mapping weer te geven. Nu, als je een N-naar-1-mapping hebt, kun je de N in de 1 plaatsen. Bij de N-to-M-mapping moet je echter over het algemeen "een kant kiezen".

In theorie zou je een van de volgende dingen kunnen doen:

1. Zet een lijst met Campaign ID s binnenkant van elke User
2. Zet een lijst met Users ID s in elke Campaign

Persoonlijk zou ik nummer 1 doen. U heeft waarschijnlijk veel meer gebruikers die campagne voeren, en u wilt de array waarschijnlijk op een kortere plaats zetten.

Stap 3:transactie

Clicks is echt een heel ander beest. In objecttermen zou je het volgende kunnen denken:Clicks "behoren tot" een User , Clicks "behoren tot" een Campaign . Dus in theorie zou je gewoon kunnen opslaan dat klikken deel uitmaken van een van deze objecten. Het is gemakkelijk om te denken dat klikken onder horen Gebruikers of campagnes.

Maar als je echt dieper graaft, is de bovenstaande vereenvoudiging echt gebrekkig. In uw systeem, Clicks zijn echt een centraal object. Je zou zelfs kunnen zeggen dat gebruikers en campagnes eigenlijk gewoon "geassocieerd zijn met" de klik.

Bekijk de vragen/vragen die je stelt. Al die vragen draaien eigenlijk om klikken. Gebruikers en campagnes zijn niet het centrale object in uw gegevens, klikken wel.

Bovendien zullen klikken de meest overvloedige gegevens in uw systeem zijn. U krijgt veel meer klikken dan wat dan ook.

Dit is de grootste hapering bij het ontwerpen van een schema voor dit soort gegevens. Soms moet u "ouder"-objecten afstoten als ze niet het belangrijkste zijn. Stel je voor dat je een eenvoudig e-commercesysteem bouwt. Het is duidelijk dat orders zou "behoren tot" users , maar orders is zo centraal in het systeem dat het een "top-level" object wordt.

Om het af te ronden

U wilt waarschijnlijk drie collecties:

1. Gebruiker -> heeft lijst met campagne._id
2. Campagne
3. Klikken -> bevat gebruiker._id, campagne._id

Dit zou aan al uw vraagbehoeften moeten voldoen:

Bekijk de informatie van elke klik zoals IP, Referer, OS, etc

db.clicks.find()

Bekijk hoeveel klikken er komen van X IP, X Referer, X OS

db.clicks.group() of voer een Map-Reduce uit.

Koppel elke klik aan een gebruiker en een campagne

db.clicks.find({user_id : blah}) Het is ook mogelijk om klik-ID's naar zowel gebruikers als campagnes te pushen (als dat zinvol is).

Houd er rekening mee dat als je heel veel klikken hebt, je echt de zoekopdrachten moet analyseren die je het meest uitvoert. U kunt niet op elk veld indexeren, dus u zult vaak Map-Reduces willen gebruiken om de gegevens voor deze zoekopdrachten te "rollen".