Как трябва да внедря тази схема в MongoDB?

Добре, мисля, че трябва да разделите това на основните „разновидности“.

Имате два обекта в стил „обект“:

• User
• Campaign

Имате един обект в стил "картографиране":

• UserCampaign

Имате един обект в "транзакционен" стил:

• Click

Стъпка 1:Обект

Нека започнем с лесните:User &Campaign . Това са наистина два отделни обекта, нито единият наистина зависи от другия за съществуването си. Освен това няма имплицитна иерархия между двете:Потребителите не принадлежат на Кампании, нито Кампаниите принадлежат на Потребители.

Когато имате два обекта от най-високо ниво като този, те обикновено печелят собствена колекция. Така че ще ви трябва Users колекция и Camapaigns колекция.

Стъпка 2:картографиране

UserCampaign в момента се използва за представяне на N-to-M картографиране. Сега, като цяло, когато имате N-към-1 съпоставяне, можете да поставите N вътре в 1. Въпреки това, с N-to-M съпоставяне, обикновено трябва да "изберете страна".

На теория можете да направите едно от следните:

1. Поставете списък с Campaign ID вътре във всеки User
2. Поставете списък с Users ID вътре във всяка Campaign

Лично аз бих направил №1. Вероятно имате много повече потребители, които провеждат кампании, и вероятно искате да поставите масива там, където ще бъде по-къс.

Стъпка 3:транзакция

Кликванията наистина са съвсем различен звяр. От гледна точка на обекта можете да мислите следното:Clicks "принадлежи на" User , Clicks "принадлежат към" Campaign . Така че на теория можете просто да съхранявате щракванията, които са част от някой от тези обекти. Лесно е да се мисли, че кликванията принадлежат под Потребители или кампании.

Но ако наистина копаете по-дълбоко, горното опростяване е наистина погрешно. Във вашата система Clicks са наистина централен обект. Всъщност може дори да сте в състояние да кажете, че потребителите и кампаниите наистина са просто „свързани“ с кликването.

Разгледайте въпросите/запитванията, които задавате. Всички тези въпроси всъщност се съсредоточават около кликванията. Потребителите и кампаниите не са централният обект във вашите данни, а кликванията.

Освен това кликванията ще бъдат най-богатите данни във вашата система. Ще имате много повече кликвания от всичко друго.

Това е най-големият проблем при проектирането на схема за данни като тази. Понякога трябва да отблъсквате „родителски“ обекти, когато те не са най-важното нещо. Представете си изграждането на проста система за електронна търговия. Ясно е, че orders ще "принадлежи на" users , но orders е толкова централен за системата, че ще бъде обект от "най-високо ниво".

Опаковка

Вероятно ще искате три колекции:

1. Потребител -> има списък с кампания._id
2. Кампания
3. Кликвания -> съдържа user._id, campaign._id

Това трябва да задоволи всичките ви нужди от заявка:

Вижте информацията от всяко щракване като IP, Referer, OS и т.н.

db.clicks.find()

Вижте колко често кликвания идват от X IP, X Referer, X OS

db.clicks.group() или стартирайте Map-Reduce.

Свържете всяко щракване с потребител и кампания

db.clicks.find({user_id : blah}) Възможно е също така да се вкарват идентификатори на кликвания както в потребители, така и в кампании (ако това има смисъл).

Моля, имайте предвид, че ако имате много и много кликвания, наистина ще трябва да анализирате заявките, които изпълнявате най-много. Не можете да индексирате всяко поле, така че често ще искате да стартирате Map-Reduces, за да „наберете“ данните за тези заявки.