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

Question

[mrBuG]

В 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.

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

Comments

[shsmad]

будут ли настройки по-умолчанию или у каждого пользователя будут храниться все настройки?

[mrBuG]

Все настройки будут по умолчанию. В том числе и вновь добавляющиеся.

Answer 1

[shsmad]

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

Answer 2

[rubyrabbit]

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

Answer 3

[Владимир Чернышев]

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

Comments

[mrBuG]

Спасибо. Вот и повод поработать с NoSQL достаточно веский :)

Answer 4

[Wott]

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

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

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

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

Answer 5

[sergei-grigorev]

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

Comments

[shsmad]

json занимает меньше места, а красота и простота обработки — на уровне xml ;)

[sergei-grigorev]

Причем тут все просто: если нет группы — настройки получаются по-умолчанию

[mrBuG]

Используя XML думаю могут возникнуть проблемы при добавлении новой настройки. Перебрать всех пользователей и все все сменить. Но если использовать общий шаблон и в базу заносить лишь то, что изменено. Как-то так мне это видится.

[sergei-grigorev]

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