Как правильно хранить пользовательские настройки в базе данных?
У меня есть база данных MySQL, в которой хранятся электронные письма пользователей и новостные статьи, которые предоставляет мой сервис. Я хочу, чтобы пользователи могли сохранять / добавлять в закладки статьи, которые они хотели бы прочитать позже.
Мой план для достижения этой цели состоял в том, чтобы в таблице, где я храню электронные письма пользователей, содержался столбец, содержащий строки уникальных идентификаторов, разделенных запятыми, где уникальные идентификаторы — это значения, назначенные каждой статье по мере их добавления в базу данных. Эти статьи хранятся в отдельной таблице, и я использую UUID_SHORT() генерировать уникальные идентификаторы типа BIGINT,
Например, скажем, в таблице, где я храню свои статьи, у меня есть
ArticleID OtherColumn
4419350002044764160 other stuff
4419351050184556544 other stuff
В таблице, где я храню данные пользователя, я бы
UserEmail ArticlesSaved OtherColumn
[email protected] 4419350002044764160,4419351050184556544,... other stuff
[email protected] 4419350002044764160,4419351050184556544,... other stuff
указать, что первые два пользователя сохранили статьи с идентификаторами 4419350002044764160 а также 4419351050184556544,
Это правильный способ хранить что-то подобное в базе данных? Если есть лучший метод, может кто-нибудь объяснить это, пожалуйста?
Еще один вариант, о котором я думал, — иметь отдельную таблицу для каждого пользователя, где я могу хранить идентификаторы статей, которые они сохранили, в столбце, хотя ответ на этот пост не очень эффективен: Эффективность базы данных — таблица на пользователя против таблицы пользователей
Решение
Я бы предложил одну таблицу для пользователя и одну таблицу для его / ее закладок.
пользователи
id - int autoincrement
user_email - varchar50
ПРЕДПОЧТЕНИЯ
id int autoincrement
article_index (datatype that you find accurate according to your structure)
id_user (integer)
Таким образом, пользователю будет легко добавлять в закладки и отменять закладки на статью. Соединение двух таблиц осуществляется с помощью id в пользователях и id_user в настройках. Убедитесь, что каждая строка в настройках / закладках является одной статьей (не делайте ничего через запятую). Делая это таким образом, вы сэкономите много времени / осложнений — обещаю!
Типичный запрос на выборку закладок пользователя будет выглядеть примерно так.
SELECT u.id,p.article_index,p.id_user FROM users u
LEFT JOIN preferences ON u.id=p.id_user
WHERE u.id='1' //user id goes here, make sure it's an int.. apply appropriate security to your queries.
Другие решения
«Правильно» — короткое слово, но предлагаемый вами подход довольно ошибочен. Полученная база данных больше не удовлетворяет даже первой нормальной форме, и это предсказывает практические проблемы, даже если вы их сразу не видите. Некоторые из проблем, с которыми вы, вероятно, столкнетесь,
- количество статей, которые каждый пользователь может «сохранить», будет ограничено типом данных
ArticlesSavedколонка; - у вас будут проблемы с дублированием «сохраненных» идентификаторов статей; а также
- запросы о том, какие статьи сохранены, будут сложнее сформулировать и, вероятно, будут выполняться медленнее; отчасти потому, что
- Вы не можете значимо индексировать
ArticlesSavedколонка.
Обычный способ моделирования отношений «многие ко многим» (например, между пользователями и статьями) — через отдельную таблицу. В этом случае такая таблица будет иметь одну строку для каждой пары (пользователь, сохраненная статья).
Сохранение данных в формате CSV в поле базы данных (почти) никогда не является хорошей идеей. У вас должно быть 3 таблицы:
- 1 таблица, описывающая пользователей со всем, что касается непосредственно пользователя
- 1 таблица с описанием статей с данными о ней
- 1 таблица с 2 столбцами «userid» и «articleid», связывающими оба. Если пользователь добавит в закладки 10 статей, в этой таблице будет 10 записей с разными атиклидами каждый раз.