Предложения по системе оповещения пользователя в MySql и PHP

Question

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

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

• В таблице уведомлений хранятся тексты уведомлений и идентификатор.
• Вариант 1: Оповещения таблица хранит все пользователи, которые прочитали уведомление
• Вариант 2: Оповещения таблица хранит все пользователи, которые не читают уведомление

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

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

Answer 1

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

100 000 записей не очень большой. Не беспокойтесь о размере, пока не получите не менее 10 миллионов записей. При необходимости архивируйте их в какой-то момент. Но вы должны сделать некоторые оценки того, как быстро вы будете генерировать 10 миллионов записей. Если это 3 дня, то да, у вас есть проблема. Если это 3 года, то вы этого не сделаете.

Этот вариант, конечно, содержит текст уведомления в отдельной таблице.

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

Разделение таблицы (пользователя, уведомления) легко: вы основываете его на пользовательских диапазонах.

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

Answer 2

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

Answer 3

Я кодирования мой наш веб-сайт и имеют один и тот же вопрос, но я решил себе этот путь:

1. хранить все записи в таблице уведомлений.
2. Read/Unread = true/false
3. CRON Job: удалять старые 10 уведомлений, если пользователь имеет более 50 уведомлений.

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