Как сохранять в бд список людей на которых подписан пользователь?

Question

[StynuBlizz]

Каким образом нужно сохранять список тех людей на которых подписан пользователь?
Будет ли правильным создать например в таблице users (таблица со всеми пользователями и их данными (пароль логин и т.д)) параметр subscriptions в котором для каждого пользователя хранить массив состоящий из id пользователей на которых он подписан?
Вот вид таблицы (на скорую руку схему сделал)

Answer 1

[Евгений Бухарев]

Не проще ли завести отдельную таблицу где писать user_id, subscribe_user_id ну и дату подписки?

Comments

[StynuBlizz]

Допустим появился 1 млн пользователей у каждого 200 друзей, пусть будет 10 физических шардов, на каждом шарде такая таблица будет состоять из 20 млн записей. И из такой таблицы списки друзей вытаскиваться будут очень часто соответственно все повалиться. А так как я выше предложил просто дернул массив и все,или я где-то ошибаюсь?

[StynuBlizz]

Добавил схему

[freeExec]

StynuBlizz: Если вам не нужен двунаправленный поиск, вроде у кого я в друзьях, то пойдет и ваш вариант с массивом.

[StynuBlizz]

freeExec: Ну а если для подписчиков просто добавить второй параметр SUBSCRIBERS и там хранить массив тех кто подписался на меня? Так пойдет? У меня просто не модель друзей а модель подписки и подписчики.

[Андрей Андреев]

И из такой таблицы списки друзей вытаскиваться будут очень часто соответственно все повалиться.

Индексы и limit вам в помощь.

[StynuBlizz]

Андрей Андреев: Но в принципе моя схема не хуже?

[freeExec]

StynuBlizz: Дублировать данные не логично и это порождает ошибки. Если вы собираетесь оперировать этими данными, то заведите отдельную таблицу для перекрёстных ссылок.

[Андрей Андреев]

Хуже, это трындец а не схема.

Как вы будите разруливать кейс когда удалили пользователя, а он у кого-то в друзьях был? Перебирать всех остальных пользователей?
Как будите проверять что один пользователь один раз в друзьях у другого пользователя?

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

Плюс если брать кейс когда будет подтверждение добавления в друзья, то его можно будет решить добавлением одно boolean поля.

И опять-же у вас будет время добавления в друзья, а это возможность для сортировки по недавно добаленным друзьям.


Таблица с ID много места не займет, с индексами это будет работать очень быстро, и если у вас будет составной уникальный индекс, то на уровне БД то на уровне БД вы не сможете подружить двух пользователей больше 2х раз.
https://www.postgresql.org/docs/9.4/static/indexes...

[StynuBlizz]

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

[StynuBlizz]

Андрей Андреев: Спасибо за разъяснение,все по полочкам разложили.Но один вопрос остался, так как у меня модель подписчики и подписки, как мне сформировать список людей который подписаны на меня?Если допустим пользователь популярный и у него 1 млн подписчиков? Как вариант можно создать две таблицы с id одна для тех кто у пользователя в подписках другая для тех кто подписан на пользователя?

[freeExec]

StynuBlizz: Потому что имея одно я могу получить другое. Если я возьму подписки всех пользователей и отберу тех которые подписаны на меня я получу второй список. И вполне может оказаться, что он не согласуется с вашим отдельным. Что вы будете делать с рассинхроном?

[Евгений Бухарев]

Допустим появился 1 млн пользователей у каждого 200 друзей, при таком варианте ваша схема с массивом загнется, как писали выше индексы решат задачу с выборкой по такой таблице. Также данную таблицу можно расширять всевозможным функционалом

Answer 2

[Cheri]

Одназночно первый вариант. Во втором варианте обратный поиск будет сложнее, к прим. вытащи мне всех людей, кто подписан мне. С реляционной моделью это проще - select user_id from smth where subscriber_id=[id of your user]. Если будешь хранить это в массиве , тебе придется пробежаться по всем данным в таблице + проверять в массиве , содержит ли он id этого пользователя.

Answer 3

[lega]

параметр subscriptions в котором для каждого пользователя хранить массив состоящий из id пользователей на которых он подписан

Да, норм, так же можно сделать массив - кто на пользователя подписан, или оба, зависит от использования.