Дизайн базы данных для обработки ленты новостей для различных действий

Я собираюсь создать новый проект, в котором мне нужно, чтобы пользователи могли просматривать действия и действия своих друзей, как в Facebook и LinkedIn.

Каждому пользователю разрешено выполнять 5 различных типов действий, каждое действие имеет разные атрибуты, например, действие X может быть общедоступным/приватным, а действие Y будет отнесено к категориям. Некоторые действия включают 1 пользователя, другие — 2 или 3 и т. д. В конце концов мне нужно объединить все эти 5 различных типов действий на странице новостной ленты.

Как создать эффективную базу данных?

Я имею в виду 3 дизайна, пожалуйста, дайте мне знать ваши мысли. Любые новые идеи будут высоко оценены!

1 – Отдельные таблицы: поскольку для каждого действия имеется около 3–4 разных столбцов, было бы логично выделить каждое действие в отдельную таблицу.
Плюсы: Чистая база данных и простота разработки.
Минусы: для создания одной страницы новостной ленты потребуется запросить базу данных 5 раз и объединить результаты.

2 – Одна большая таблица. В этой таблице будут храниться все действия с большим количеством неиспользуемых столбцов. Будет добавлен новый числовой столбец под названием «тип», который будет указывать тип активности. Некоторые атрибуты могут быть объединены в поле HStore (поскольку мы используем Postgres), другие будут часто запрашиваться, поэтому я не думаю, что это хорошая идея включать их, как в поле HStore.
Плюсы:< /strong> Легко получить ленту новостей.
Минусы: Много операций чтения/записи в одной и той же таблице, код будет немного беспорядочным, как и база данных.

3 – Гибрид: решением было бы создать одну таблицу, содержащую всю ленту новостей, с полиморфной ассоциацией с другими таблицами, содержащими сведения о каждом конкретном действии.
Плюсы: Аккуратный код и база данных, легко добавлять новые действия.
Минусы: ОБЪЕДИНЯЙТЕ ВСЕ ТАБЛИЦЫ, чтобы создать единую ленту новостей! Все же лучше, чем делать 5 разных запросов.

Когда я пишу этот пост, я начинаю склоняться к решению номер 2. Пожалуйста, посоветуйте!

Спасибо


person wael34218    schedule 20.05.2014    source источник


Ответы (1)


Я бы рассмотрел для этого графовую базу данных. Neo4j. Это добавит очень гибкие атрибуты либо узлам (пользователям), либо ссылкам (типам отношений).

Для небольших наборов и нескольких объединений базы данных SQL работают быстрее и более подходят. Но если вашей отправной точкой является 5 объединений таблиц, графовые базы данных кажутся более простыми и обеспечивают аналогичную производительность (если не лучшую).

person mjalajel    schedule 20.05.2014