Как лучше организовать систему уведомлений?

Question

[xXRustamXx]

Есть проект, подобие социальной сети, в нем есть: подписки, комментарии и лайки к постам.
Встал вопрос о добавлении уведомлений, первое в голову пришло это хранить уведомления в таблицах, вот пример:

Но я наткнулся на следующий подход:
В таблицах posts/posts_likes/users_subs/users_followers добавлять колонку status=new|read и по этой колонки определять сколько уведомлений не было прочитано и их собственно отдавать пользователю.
Очевидно что второй вариант - более выгоден с точки зрения памяти в БД, да и таблицы новые не нужно создавать. Есть ли более лучшие варианты для организации системы уведомлений?

Comments

[Zhainar]

что такое уведомления в вашем случае? как у уведомлений могут быть лайки, подписки, комменты и тд?

Answer 1

[Иван Шумов]

А что будет с несколькими разнотипными устройствами?)

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

Comments

[xXRustamXx]

Не совсем понятно, что значит в "стерилизованном виде", типо html строка? Что за очереди, есть пример или дока? Я хочу сделать вывод уведомлений по аналогии с социальной сетью vk.com

[Иван Шумов]

xXRustamXx, "сериализированном". опечатка) Очереди, например - RabbitMQ

[Иван Шумов]

xXRustamXx, а выводить уведомления отдельно это плохая практика. Не надо путать уведомления и ленту активности

[xXRustamXx]

Иван Шумов, Пример с MongoDB:

{
  id: 1,
  type:  "like",
  userId: 1,
  isRead: false,
  data: {
    postId: 357,
    likedUserId: 49
  }
}

Здесь конечно удобно, но есть минус, при удалении поста нужно будет делать дополнительные запросы в MongoDB, или есть обходные варианты?

[Иван Шумов]

xXRustamXx, при удалении поста имеет смысл удалять или маркировать все связанные (логически) объекты. А вообще, лента активности не хранится долго. Иначе вам никакой базы данных не хватит

[Иван Шумов]

xXRustamXx, А вообще можно не удалять. Ничего плохого не вижу в том чтобы показывать при переходе "пост не существует или был удален". Или еще что. Разные причины могут быть, например "пост заблокирован по решению Роскомнадзора"

[xXRustamXx]

Иван Шумов, А как же join-ы? Мне придется доставать уведомления из MongoDB и проходиться по ним выдергивая данные поста и т.д. из postgresql

[Иван Шумов]

xXRustamXx, такие системы не строятся на монолитах, а тольк она микросервисной архитектуре. Поэтому придется использовать другие подходы

Answer 2

[xmoonlight]

Уведомление - присылает не юзер, а система. Поэтому поле senderUserId - лишнее, как и receiverUserId.

Полей должно быть всего 5:
id:uint,
type:uint,
userId:uuid,
isRead:bool,
created:timestamp

А кто именно прислал и какое именно уведомление, находим через таблицу типов уведомлений notification_type.
А там: id и notifycation_table (у Вас их 4. те, что слева).
Используя id(уведомления), notifycation_table и userId (для кого уведомление), мы находим сразу все подробности нужного уведомления.

Т.е, поиск ведём от общей таблицы уведомлений в 3 итерации: "погружение" выборки (запрос будет один, разумеется, но выполнится он гораздо быстрее), а не наоборот (как сейчас сделано у Вас).

Comments

[xXRustamXx]

Я немножко запутался, не могли бы вы пожалуйста свою мысль перенести сюда https://dbdiagram.io/d/5f3a716a39081a20ae94d199

[xXRustamXx]

Про это имелось ввиду?

[xmoonlight]

xXRustamXx, да, и notification_types ещё таблица должна быть.

[xXRustamXx]

xmoonlight, Это все равно не то, потому-что при удалении row из notification не потянет за собою row из таблиц notifycation_table

[xmoonlight]

xXRustamXx, не понятно ничего. Что и откуда не потянет? И зачем удалять нужно? Есть же статус.

[xXRustamXx]

xmoonlight, В первом варианте статуса нету, он только во втором есть, у меня это описано в вопросе

Answer 3

[alekseyHunter]

Я юзаю Firebase и запросы к нему с сервера. Это если уведомления - PUSH.
Если уведомления внутри приложения, тут лучше web-socket.