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

Question

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

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

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

   • notifiable_type
   • notifiable_id
   • user_id
   • действие
   • notifiable_cache (необязательно, сохраняет хэш выбранных атрибутов из уведомляемого объекта)

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

   • user_id
   • название
   • сообщение

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

Answer 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 

Answer 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)

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

Answer 3

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

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

Answer 4

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

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

Answer 5

поддержка уже есть 2 модели:

- users - id - name - notifications - id - title - content

Я создам новую модель: - user_notifications - id - user_id - notification_ids: Array[]

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

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

Answer 6

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

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

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

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

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

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