Сведения о вопросе

Oleksandr

15:53, 16th August, 2020

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

Просмотров: 393   Ответов: 5

В web-проекте планируется достаточно много настроек для пользователей. Так же в будущем их придется добавлять/убирать.
Рассматривается несколько вариантов хранения значений этих настроек:

1. Создать две таблицы (при условии, что таблица с user_id уже есть):
1) option, option_id;
2) user_id, option_id, value.
2. Хранить все в одной дополнительной таблице: user_id, all_options_format(xml|json). В данном случае все настройки будут в одну строку формата xml или json.
3. Опять же дополнительная таблица но уже вида: key(user_id, option), value.

Какой из этих вариантов на ваш взгляд предпочтительнее?



  Сведения об ответе

park

17:05, 28th August, 2020

Храните в отдельном месте настройки по-умолчанию. Для пользователей храните в json/xml виде только отличающиеся от дефолтных настройки. Суммарные настройки пользователя получатся путем наложения отличающихся на настройки по-умолчанию. Таким образом при добавлении новой настройки изменится только один конфиг — общий, и тем не менее он будет доступен у пользователя. А при изменении пользователем такой настройки измененное значение запишется в его личный конфиг.


  Сведения об ответе

ЯЯ__4

13:47, 10th August, 2020

Если говорить про MySQL, то в PunBB, например, как наиболее быстрый вариант выбрали хранение настроек прямо в таблице users: каждой настройке свой столбец.
Если вы часто меняете перечень настроек, то проще вынести их в отдельную таблицу, где ключом будет user_id, а в столбцах будут сами настройки.
Тогда можно одним запросом получить данные сразу в готовом виде, экономить тут смысла особо нет, зато можно делать сложные запросы в случае чего.
А в общем конечно лучше использовать NoSQL для этого.


  Сведения об ответе

SEEYOU

19:59, 29th August, 2020

Mongo или Couch (да и наверняка многие NoSQL) для хранения данных, которые естественно представляются в виде XML/JSON (дерево значений с атрибутами) подходит идеально. Хранить и работать с деревьями в SQL вообще не сахар, а уж когда жёсткой схемы нет…


  Сведения об ответе

SILA

04:56, 19th August, 2020

Если хранить как поле=значение, то появляется недостаток в обработке вложенных свойств. Например, у приложения есть окна, и в каждом окне может быть применен свой стиль. Естественно, что все, что принадлежит данному окну, группируется «в виде дерева». В данном случае удобен XML. Недостаток такого метода думаю ясен — приходится загружать полностью все поле, а затем его обрабатывать. Но достоинство — все красивенько сгруппировано, не сложно обрабатывать и не сложно отобразить в каком-либо отчете


  Сведения об ответе

lats

10:10, 20th August, 2020

Вы неправильно ставите вопрос. как хранить — без разницы, данные от этого не испортятся. Вопрос в том что вы будете с ними делать. И тут есть варианты:

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

Если же опции используются скопом, например при рендере страницы для него и больше никак, то есть смысл упаковать массив в виде json/xml.

Мне лично нравиться вариант Wordpress, где есть отдельная таблица для именованных опций ( юзера, поста и что там еще ) и в ней храниться либо отдельное значение или массив в виде отдельных строк, но с одним именем, по которым можно делать выборку или сериализованный массив — по желанию. Точнее как удобно их использовать. И при желании все варианты можно миксовать.


Ответить на вопрос

Чтобы ответить на вопрос вам нужно войти в систему или зарегистрироваться