Создание системы уведомлений

Ответ 1

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

╔═════════════╗      ╔═══════════════════╗      ╔════════════════════╗
║notification ║      ║notification_object║      ║notification_change ║
╟─────────────╢      ╟───────────────────╢      ╟────────────────────╢
║ID           ║—1:n—→║ID                 ║—1:n—→║ID                  ║
║userID       ║      ║notificationID     ║      ║notificationObjectID║
╚═════════════╝      ║object             ║      ║verb                ║
                     ╚═══════════════════╝      ║actor               ║
                                                ╚════════════════════╝

(Добавьте поля времени, где вы сочтете нужным)

Это в основном для группировки изменений для каждого объекта, чтобы вы могли сказать "У вас есть 3 запроса друзей". И группировка на актера полезна, так что вы можете сказать: "Пользователь Джеймс Бонд внес изменения в вашу кровать". Это также дает возможность переводить и подсчитывать уведомления по своему усмотрению.

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

Так как уведомления близки к реальному времени для пользователей на сайте, я бы привязал их к узлу nodejs + websockets client с обновлением php, чтобы обновить nodejs для всех слушателей по мере добавления изменений.

Ответ 2

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

Вот что я думаю о ваших проблемах:

• Да, система уведомлений сложна, но не так. У вас может быть много разных подходов к моделированию и внедрению таких систем, и они могут иметь от среднего до высокого уровня сложности;

• Песняльно, я всегда стараюсь сделать базу данных управляемой. Зачем? Потому что я могу гарантировать полный контроль над всем, что происходит - но это только я, вы можете контролировать без подхода, основанного на базе данных; поверьте мне, вы захотите контролировать этот случай;

• Позвольте мне показать вам реальный случай, чтобы вы могли начать где-то. В прошлом году я смоделировал и реализовал систему уведомлений в какой-то социальной сети (конечно, не как facebook). Как я использовал для хранения уведомлений? У меня была таблица notifications, где я сохранил generator_user_id (идентификатор пользователя, который генерирует уведомление), target_user_id (вид очевидного, не так ли?), notification_type_id (что ссылаются на другую таблицу с типами уведомлений), и все необходимое для заполнения нам нужно заполнить нашими таблицами (отметки времени, флаги и т.д.). В моей таблице notification_types использовалось отношение с таблицей notification_templates, в которой хранились определенные шаблоны для каждого типа уведомлений. Например, у меня был тип POST_REPLY, у которого был тип шаблона вроде {USER} HAS REPLIED ONE OF YOUR #POSTS. Оттуда я просто рассматривал {} как переменную и # как ссылку ссылки;

• Да, производительность должна и должна быть в порядке. Когда вы думаете об уведомлениях, вы думаете о том, что сервер нажимает с головы до ног. Либо если вы собираетесь делать это с помощью ajax-запросов или чего-то еще, вам придется беспокоиться о производительности. Но я думаю, что во второй раз беспокоюсь,

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

Ответ 3

╔════════════════════╗
║notification        ║
╟────────────────────╢
║Username            ║
║Object              ║
║verb                ║
║actor               ║
║isRead              ║
╚════════════════════╝

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

Сообщите мне, есть ли проблема с этой схемой.

Ответ 4

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

Усовершенствования хорошо приняты.