Дизайн базы данных для хранения уведомлений пользователям

Я работаю на веб-сайте сообщества литературы. (screenshot) И я пытаюсь выяснить, как уведомлять пользователей, когда кто-то комментирует что-то, что они отправили на сайт, когда кто-то смотрит подает новый литературный фрагмент и т.д.

Я пытаюсь выяснить, как структурировать базу данных для хранения этой информации. Я придумал две возможные идеи.

Сохраните ссылку на подлежащий уведомлению объект, поле, описывающее тип действия (новое, обновление и т.д.), о котором уведомляется пользователь. Это делает сложный код отображения, но это означает, что я могу изменить, как уведомления работают довольно легко. Это также увеличивает данные, которые мне нужно вытащить из базы данных, если я не использую поле кеша для сброса хэша соответствующих атрибутов в таблицу.
- notifiable_type
- notifiable_id
- user_id
- действие
- notifiable_cache (необязательно, сохраняет хеш выбранных атрибутов из объекта, подлежащего уведомлению)
Относитесь к уведомлениям, таким как электронная почта, и просто сохраняйте их в базе данных с темой и сообщением. Это приводит к простому представлению, но сложной модели и не позволяет мне легко изменять работу уведомлений.
- user_id
- название
- сообщение

Я ищу другие идеи и комментарии по двум перечисленным выше.

Ответ 1

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

Notifications:  
- ID (PK)
- recipient_id
- sender_id
- activity_type ('comment on a post', 'sent friend request', etc) 
- object_type ('post', 'photo', etc)
- object_url (to provide a direct link to the object of the notification in HTML)
- time_sent
- is_unread

Ответ 2

message :
-id_message(pk)
-to 
-from 
-subject
-message
-status (read,unread)

reply_message :
-id_reply(pk)
-id_message
-from
-message
-status (read,unread)

notification :
-id_user
-id_notify(pk)
-notify_type (message, or reply_message)
-notify_desc (comment/reply on your message)
-status (look,unlook)

notify_detail : (for notify, when user reply or comment more than 1)
-id_notify
-id_sender
-id_detail (input id_message, id_reply)

как насчет этого? вы можете смешать его с комментарием или комментарием.

Ответ 3

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

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

Ответ 4

Недавно я сделал это в бэкэнде Rails приложения iOS и в основном использовал (2) с меткой времени, но сохранен в списке Redis, индексированном пользователем. Более слабая схема (со всем, что в основном написано в "сообщении" ) позволяет нам двигаться намного быстрее во время разработки и ранних бет.

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

Ответ 5

Я не совсем уверен, что такое поле action в # 1, но если я правильно понимаю вашу потребность, вы, по сути, хотите, чтобы пользователи подписались на очередь уведомлений, правильно? Эти уведомления предназначены для отправки пользователю по электронной почте или отображаются только при входе в систему или в обоих случаях?

У меня возникнет соблазн подумать об этом как о очереди, где вы "публикуете" уведомления, и пользователи "подписываются" на любое уведомление со своим user_id, связанным с ним. В реляционной схеме вы, вероятно, хотите использовать что-то вроде # 1, где у вас есть уведомление с типом, связанным с пользователем. Конечно, указатель на user_id, чтобы вы могли быстро получать свои уведомления. Если вы будете много раз просить об этом, кеширование, которое вам нужно для целей показа, имеет большой смысл, так что вам не нужно вступать ни в какие другие таблицы, что при условии, что отображаемые данные не могут измениться после уведомление было отправлено.

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

Вам также нужно убедиться, что вы обрезаете таблицу. Вам может потребоваться добавить флаг, чтобы указать, что пользователь уже видел уведомление, но в идеале, как только они его увидели, вы можете удалить его, и это будет держать таблицу маленькой.

Другой альтернативой является сохранение уведомлений за пределами ваших rdbms. Рассмотрите возможность хранения уведомлений в memcached, например, если возможность их потери приемлема (если сервер, например, идет вниз). Или посмотрите на Redis (http://code.google.com/p/redis/), что очень упростит эту проблему - сохранит уведомления и создаст набор для каждого пользователя, и вы почти закончили.

Просто подумайте, надеюсь, что они полезны.