2016-12-21 2 views
0

Я ищу толчок в правильном направлении, в основном на стороне базы данных, но принимается любой тип push (код мудрый!) Относительно системы уведомлений от 1 до многих.1 для многих систем уведомлений

где куча пользователя получает уведомление, вызванное интересами пользователей (например, другим пользователем).

Пример

  • user1, user2 и user3 заинтересованы в Subject A.
  • Тема А, размещена активность.
  • user1, user2 и user3 получает уведомление от Subject A.
  • user2 и user3 просмотрели обновление, поэтому они больше не будут уведомлены об этом обновлении.
  • user1 по-прежнему получает уведомление, потому что еще не просмотрел обновление.

The Magic: Тысячи пользователей могут и будут продолжать получать такое же уведомление, но отдельные пользователи перестанут получать уведомления, если они рассматривают или взаимодействовать с обновлением.

Моя реализация

я построить таблицу уведомлений в моей БД как

id | sender | context | action | receiver | unread 
1 | Nobel | Prize | Won | Moi  | true #default 

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

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

Мое мнение

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

Вопрос: есть лучший способ сделать это.

+0

Вы должны четко указать (сначала себе, а затем на нас) то, что вы на самом деле требуете, потому что это будет иметь большое влияние на вашу базу данных: это уведомление, помеченное на основе уведомлений (как в письмах) или вы отмечаете старые уведомления как прочитанные, если вы читаете более новую (как в чат-приложениях); также актуально: за «последователей» (например, chat/twitter) или во всем мире (например, групповой или некоторые форумы)? Вы можете даже рассчитать свои уведомления динамически: если у вас есть такие правила, как «Сообщение с сообщениями с тегом B, пользователь получает заметки по мере того, как он следует A или B», вы можете рассчитать, что «на лету» (экономит место, затрачивает время) – Solarflare

+0

Большое спасибо , Я думаю. –

ответ

2

Очевидная альтернатива заключается в том, чтобы хранить уведомление только один раз и хранить флаг чтения/непрочитанного отдельно как notificationID, userID. «Чтение» показалось бы более безопасным, поскольку он лучше справляется с неактивными пользователями.

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

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

Смежные вопросы