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

Question

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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 4

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

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

Answer 5

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

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