Jak zaimplementować ten schemat w MongoDB?

OK, myślę, że musisz podzielić to na podstawowe „odmiany”.

Masz dwa obiekty w stylu „entity”:

• User
• Campaign

Masz jeden obiekt w stylu „mapowania”:

• UserCampaign

Masz jeden obiekt w stylu „transakcyjnym”:

• Click

Krok 1:podmiot

Zacznijmy od prostych:User &Campaign . To są naprawdę dwa oddzielne obiekty, żaden z nich nie zależy tak naprawdę od drugiego, jeśli chodzi o jego istnienie. Nie ma również dorozumianej hierarchii między nimi:użytkownicy nie należą do kampanii ani kampanie nie należą do użytkowników.

Kiedy masz dwa takie obiekty najwyższego poziomu, zazwyczaj zdobywają one własną kolekcję. Więc będziesz chciał Users kolekcja i Camapaigns kolekcja.

Krok 2:mapowanie

UserCampaign jest obecnie używany do reprezentowania mapowania N-do-M. Teraz, ogólnie rzecz biorąc, kiedy masz mapowanie N-do-1, możesz umieścić N wewnątrz 1. Jednak przy mapowaniu N-to-M generalnie musisz "wybrać stronę".

Teoretycznie możesz wykonać jedną z następujących czynności:

1. Umieść listę Campaign ID s wewnątrz każdego User
2. Umieść listę Users ID s wewnątrz każdej Campaign

Osobiście zrobiłbym #1. Prawdopodobnie masz znacznie więcej użytkowników, którzy prowadzą kampanie, i prawdopodobnie chcesz umieścić tablicę tam, gdzie będzie ona krótsza.

Krok 3:transakcyjny

Clicks to naprawdę zupełnie inna bestia. W kategoriach obiektowych możesz pomyśleć, co następuje:Clicks "należą do" User , Clicks „należą do” Campaign . Tak więc teoretycznie możesz po prostu przechowywać kliknięcia, które są częścią jednego z tych obiektów. Łatwo pomyśleć, że kliknięcia należą do pod Użytkownicy lub kampanie.

Ale jeśli naprawdę poszukasz głębiej, powyższe uproszczenie jest naprawdę wadliwe. W Twoim systemie Clicks są naprawdę centralnym obiektem. W rzeczywistości możesz nawet powiedzieć, że użytkownicy i kampanie są tak naprawdę „powiązane” z kliknięciem.

Spójrz na pytania / zapytania, które zadajesz. Wszystkie te pytania w rzeczywistości koncentrują się wokół kliknięć. Użytkownicy i kampanie nie są głównym obiektem Twoich danych, ale kliknięcia są.

Dodatkowo Kliknięcia będą najobfitszą ilością danych w Twoim systemie. Będziesz mieć znacznie więcej kliknięć niż cokolwiek innego.

Jest to największy problem przy projektowaniu schematu dla takich danych. Czasami trzeba odepchnąć obiekty „rodzice”, gdy nie są one najważniejsze. Wyobraź sobie budowanie prostego systemu e-commerce. Oczywiste jest, że orders będzie „należeć do” users , ale orders jest tak ważny dla systemu, że będzie obiektem „najwyższego poziomu”.

Zawijanie

Prawdopodobnie będziesz potrzebować trzech kolekcji:

1. Użytkownik -> ma listę kampanii._id
2. Kampania
3. Kliknięcia -> zawiera user._id, Campaign._id

Powinno to zaspokoić wszystkie Twoje potrzeby związane z zapytaniami:

db.clicks.find()