Привет всем. Мы разрабатываем приложение для просомтра расписания. У нас

Question

Привет всем. Мы разрабатываем приложение для просомтра расписания. У нас

суть такая, что юзер создает подписку на определенную подгруппу и может следить за расписанием этой подгруппы.
У нас практически вся инфа обновляется в реалтайме. Обновленные айдишники отсылаем по веб-сокетам. Если, например, обновилась модель Lecturer, то чтобы понять, каким юзерам отсылать обновленные айдишники, я добираюсь через 4-5 таблиц 😅 Я просто недавно узнал о том, что это пздц (не бейте)))
И практически так же другие таблицы...
В общем, хотел узнать, есть ли какой-то вариант как-то оптимизировать этот процесс? Может быть через какую-то промежуточную таблицу? Но было бы ок сделать ее какую-то универсальную что ли, эту промежуточную таблицу.

#backend #devops #pgsql #programming #russian

0

30.12.2019

3 ответов

12 просмотров

Ilya Zviagin

Тут другая может быть проблема, вот 100 пользователей у тебя, один меняет данные -- надо разослать уведомление 99и пользователям. (почти 100). 2 пользователя -- почти 200ам. Все меняют -- это будет почти 100 * 100, то есть сложность задачи N**2

0

30.12.2019

Yuriy Yarosh

1) В Occuoation лучше транзитивный Composite PK использовать из occupation_id и faculty_id 2) В group'aх лучше использовать низходящий либо восходящий рекурсивный обход, т.е. табличка Subgroup не нужна и стоит научиться в рекурсивный select через parent_group_id например 3) В subscription флаг is_main не нужен т.к. может привести к index или table scan'у ... d user'e лучше сделать nullable main_subscription_id например ... В общем могу продолжать. ID'шкы у вас не должны меняться, и стоит ещё в каскадирование для FK научится ...

0

30.12.2019

Ilya Zviagin · Accepted Answer

Ilya Zviagin

В чём Pi__ец ?

0

30.12.2019

172 похожих чатов

Привет всем. Мы разрабатываем приложение для просомтра расписания. У нас

3 ответов

Похожие вопросы