Дизайн шаблона: система уведомлений

Question

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

Я хотел бы внедрить систему уведомлений, которая показывает такие вещи, как «X добавил вас в друзья», «Y пригласил вас на вечеринку», «Z выполнил последний тест» ... и я не знаю как это сделать.

Интересно, какое решение лучше:

• Решение 1, он же «ведение журнала».

Выделенная таблица «Уведомление». Я добавляю строки в эту таблицу каждый раз, когда происходит оповещение (добавление друзей, ответы на вопросы и т. Д.). Таблица «Уведомление» имеет поля, которые содержат различную информацию в зависимости от того, какой тип уведомления добавлен в таблицу.

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

Плохо : таблица уведомлений, вероятно, будет очень большой (думаю, я добавлю в таблицу 10 000 строк / день), «дублированная» информация: информацию в таблице уведомлений можно найти во всех других таблицах. используя дату / список / любое сравнение.

• Решение 2, иначе "смотреть везде".

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

Хорошо : не слишком большая таблица по сравнению с решением 1, нет «избыточности» информации.

Плохо : Я боюсь из-за количества пользователей (~ 1k +), он заставляет сервер взорваться, потому что он требует ресурсов / времени, немного сложнее для кодирования / обслуживания.

Можете ли вы сказать мне, что вы считаете лучше и почему, или у вас есть решение, которое я не представлял?

Спасибо =)

---

Редактировать: Допустим, я использую действительно базовый дизайн БД: у пользователей есть друзья, они могут делать викторины.

1 таблица для списка пользователей, списка вопросов,

1 таблица quizz <-> отношение пользователя,

1 пользователь таблицы <-> для дружбы.

Каждый раз, когда пользователь посещает свой собственный профиль, он может видеть, что произошло: новая анкета <-> пользовательская связь, новый пользователь <-> пользовательская связь и т. Д. Как бы вы создали такое уведомление?

Answer 1

Создайте системную очередь, каждое сообщение, добавленное в эту очередь, имеет список «потребителей» и контент. Главный насос сообщений обрабатывает каждое сообщение и отправляет сообщение всем потребителям.

Допустим, 2 человека дружат друг с другом. Вы добавляете сообщение в основную системную очередь, что A дружит с B, а потребители - и A, и B. Когда ваше сообщение «насос» (процессор) видит это сообщение, оно добавляет его в очередь A и очередь B. Итак теперь пользователь A и пользователь B получили новое сообщение о том, что они друзья. В свою очередь, у каждого пользователя есть обработчик сообщений, поэтому, когда он видит сообщение под названием «Я дружу с [кем-либо]», он обрабатывает его как добавление новой записи на «стене», видимой для друзей А, что «А дружит с Б и т. д.

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

Вам решать дизайн.

Answer 2

На самом деле это подпадает под как мне проектировать автомобиль? тип вопроса категории ...

Реализация зависит от проекта, куда он пойдет в будущем, и среды, в которой вы будете внедрять. Вы можете выбрать реализацию в стиле twitter, систему с поддержкой SAN XML, реляционных баз данных, Hadoop и множество других.

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

Каковы ваши требования к производительности? Уровни трафика? Пользовательские требования? Вы хотите распространять позже (например, через веб-хуки?).

Ваш вопрос должен быть более конкретным.

У меня лично будет таблица "типов уведомлений", действующих как enum ..., а затем таблица уведомлений пользователя <>, обрабатывающая отношения между уведомлением и пользователем.

При хорошем кодировании вы можете распределить таблицу уведомлений пользователя <> по многим серверам и указать идентификатор пользователя или аналогичный ... и реплицировать таблицу типов по каждому из этих узлов для локального кэша / ссылки. Нечто подобное.

Answer 3

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

Надеюсь, это поможет другим, ищущим подобные решения.

Answer 4

Я предлагаю использовать простые уведомления. Нет типа уведомления или что-то еще.

Уведомления
-id
-message
-href (ссылка, по которой пользователь нажимает на уведомление)
-receiverUser
-date

Пример использования: Джону (34 года) понравилась фотография Марии (47 лет). (Мы отправляем уведомление Мэри)

INSERT INTO Notifications(message,href,receiverUser, date) VALUES ('John liked your photo', 'link of the photo', 47, 01.11.2014)