Несколько записей базы данных в таблице и запросы к базе данных? Что лучше для производительности?

Question

App работает на: ruby 2.0, rails 4 и postgresql

1.The несколько таблиц истории - Как это работает сейчас:

project имеет много users как members.

Также project имеет много posts, когда post создается notification создается для каждого project user.

Скажем, если Проект A имеет 100 пользователей, мы будем иметь 100 уведомлений в базе данных, это будет загрузить базу данных с большим количеством дублей.

Но пользователь может удалить свое собственное уведомление, просмотреть его, мы можем обновить его уведомление с помощью конкретных данных. И мы будем использовать команду rake, чтобы удалить уведомления, которые старше, чем определенный интервал времени.

2. Множественные запросы БД - То, что мы хотим сделать:

Существует идея создания только один уведомления для деятельности и использовать многие ко многим отношений с таблицей называется notifications_users где мы будем хранить информацию об уведомлении, если он был прочитан текущим пользователем, если этот пользователь удалил это уведомление со своей вкладки уведомлений и т. д.

Недостатком этого я считаю, что это будет несколько запросов db, когда нам нужно найти что-то abou t уведомление и пользователь, мы должны будем найти таблицу notification_users, чтобы получить необходимую информацию.

Кроме того, создавая отношения таким образом, будет сложнее очистить базу данных от старых уведомлений, поскольку мы не будем знать, было ли это уведомление прочитано или нет каким-то пользователем.

спасибо.

Answer 1

Вариант (1.) представляется довольно разумным, и если вы можете сохранить модель уведомления тонкой - например user_id, activity_id, timestamps и, возможно, еще пару флагов, то не ожидайте необоснованных штрафных санкций, поскольку это выглядит довольно обычная реляционная модель, и я бы ожидал, что база данных будет легко справляться с ней.

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

В Assembla.com мы делаем уведомление по электронной почте, и это работает очень хорошо для нас, я бы сказал. Таким образом, возможно, в какой-то момент вам может понадобиться рассмотреть этот вариант.

Мне кажется, что (2.) просто не отвечает потребностям бизнеса, и если вы не рассматриваете их, это, вероятно, не стоит рассматривать этот вариант.

Answer 2

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

1) Также проект имеет много сообщений, когда создается сообщение, для каждого пользователя проекта создается уведомление.

2) Предположим, если в проекте A есть 100 пользователей, у нас будет 100 уведомлений в базе данных, это приведет к загрузке базы данных с большим количеством дубликатов.

Заявление №. 1 описывает, что при создании сообщения; для каждого пользователя отправляется уведомление. Предположим, что 100 пользователей и 100 сообщений, тогда таблица, в которой есть данные для уведомлений, будет иметь 10000 строк (100 * 100).

Заявление №. 2 описывает, что, если есть 100 пользователей, тогда в базе данных будет 100 уведомлений, что означает, что таблица уведомлений будет содержать 100 строк.

Из приведенных выше пунктов, которые следует рассмотреть.