Проектиране на схема на база данни MongoDB

Бих използвал следната структура:

1. Използвайте една колекция за всички случили се действия, Actions

2. Използвайте друга колекция за кой кого следва, Subscribers

3. Използвайте трета колекция, Newsfeed за новинарската емисия на определен потребител, елементите се разклоняват от Actions колекция.

Newsfeed колекцията ще бъде попълнена от работен процес, който асинхронно обработва нови Actions . Следователно новинарските емисии няма да се попълват в реално време. Не съм съгласен с Geert-Jan в това, че реалното време е важно; Вярвам, че повечето потребители не се интересуват дори от минута забавяне в повечето (не всички) приложения (за реално време бих избрал напълно различна архитектура).

Ако имате много голям брой consumers , раздуването може да отнеме известно време, вярно. От друга страна, поставянето на потребителите направо в обекта също няма да работи с много голям брой последователи и ще създаде прекалено големи обекти, които заемат много индексно пространство.

Най-важното обаче е, че дизайнът на вентилатор е много по-гъвкав и позволява оценяване на уместност, филтриране и т.н. Съвсем наскоро написах публикация в блога за дизайна на схемата на емисиите на новини с MongoDB, където обяснявам част от тази гъвкавост по-подробно.

Говорейки за гъвкавост, бих бил внимателен за спецификацията на activitystrea.ms. Изглежда, че има смисъл като спецификация за взаимодействие между различни доставчици, но не бих съхранявал цялата тази подробна информация в моята база данни, стига да не възнамерявате да агрегирате дейности от различни приложения.