Какой эффективный способ реализации избранного/корзины пользователя в базе данных?

Question

[Pavel]

Существует таблица пользователя, в которой имеется поле favorites. (например, статьи в избранном)
Статьи хранятся условно в таблице articles (id, name, desctiption, date, etc.)

Задача заключается в том, чтобы реализовать индивидуальный список Избранного для пользователя, то есть у каждого пользователя должен быть раздел Избранное, данные которого хранятся в бд. Нужен эффективный способ.

Если вы поняли о чем речь, вам не обязательно читать дальше)

Я привел ниже 3 варианта решения задачи, но они мне не нравятся. Я не ищу обсуждения способов ниже (хотя приветствуется), а, скорее, проверенного best practices (или просто хорошего) Вашего решения проблемы, либо задайте направление для исследования вопроса.

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

Пока имеется 3 способа реализации данной идеи:

1. сделать таблицу favorite, которая будет содержать все необходимые данные Избранного (название, описание, картинка или, условно, просто id нужной записи в таблице articles) + nickname юзера, который ее добавил в избранное. В итоге получается полнейший бардак - в таблице будут все favorite-статьи всех пользователей, а выборка будет производиться (наверняка долгим) парсингом по нику пользователя.

2. таблица user: в поле favorite хранится имя персональной таблицы Избранное для пользователя (рандом, например, 8hafhq2ij). Для получения данных придется получить имя таблицы и потом все ее данные (8hafhq2ij).

3. в таблице user: в поле favorite просто записывать id нужных статей в формате "1 2 18 21 212", а потом просто вытаскивать и в массив закидывать, который можно использовать для получения конкретных статей по их id в таблице articles.

PS: предполагается количество пользователей от 10к с активным использованием функции добавления.

Имею понимание теории бд, но на практике ничего серьезнее "электронного журнала" не было

Answer 1

[Оптимус Пьян]

Так может отдельная таблица favorites с полями id, id_articles, id_user
Выборка: выбрать все id_articles где id_user=13

Корзину например можно сделать переносом статьей в отдельную таблицу с сохранение старого id а можно просто скрыть их путём ввода поля "видимость" 1 и 0. Если корзину чистим - все статьи где vision=0 удаляются из БД например.

Comments

[Pavel]

спасибо! А если пользователей будет 10к, количество записей favorites вырастет до сотен тысяч. При выборке для одного пользователя (с 15 записями в избранном) придется выбирать в таблице с размером в 100к+ записей. Я понимаю, что может не значительным быть время выборки, является ли это правильным решением?

[Оптимус Пьян]

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

[Сергей]

Называется такая таблица Junction table и лучше делать её из двух полей UserId, ArticleId первичный ключ кластерный UserId+ArticleId и два FK.

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

[Игорь]

поле ID лишнее, достаточно ID_ARTICLES и ID_USERS и сделайте уникальный индекс на этих полях // UNIQUE(ID_ARTICLES, ID_USERS)