Хранение очень детальных пользовательских настроек

Question

Я видел здесь несколько вопросов о хранении пользовательских настроек, но, похоже, они в основном относятся к довольно минимальному набору предпочтений. В настоящее время я работаю над настраиваемым веб-приложением, в котором нужно будет хранить большое количество настроек, и я борюсь с тем, как их хранить.

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

Я не большой поклонник сериализации, но меня беспокоит масштабируемость сохранения каждого предпочтения в виде отдельной строки. Мысли? * * 1005

Answer 1

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

Модель сущности-атрибута-значения, о которой упоминает HLGEM, подходит для этого с точки зрения «простого развития», но, по его словам, будет иметь очень плохую производительность.

Что бы вы отказались от сериализованных объектов, так это возможность напрямую запрашивать БД для пользователей, соответствующих определенному шаблону (возможно, вы отслеживаете ошибку, которая может возникнуть только при некоторой комбинации настроек, и вы хотите увидеть, у вас есть пользователи, которые имеют эту комбинацию).

Answer 2

что бы вы не использовали для этого структуру entity-attrivute-value (http://en.wikipedia.org/wiki/Entity-Attribute-Value_model), если только вам не нужна очень плохо работающая система. Вызов одной таблицы с 50 столбцами будет намного быстрее, чем вызов к одному столу, к которому нужно присоединиться 50 раз, чтобы получить всю необходимую информацию.

Я бы сделал связанную таблицу для каждой общей группы предпочтений (настройки входа в систему, общие настройки сайта, настройки конкретной страницы или функции), основываясь на том, как вы намереваетесь запрашивать настройки (если вы хотите вернуть все обратно при входе в систему). Тиски тянут те, которые нужны для всего сайта при входе в систему, и те, которые нужны только для специализированных областей, когда пользователь нажимает на них, поэтому некоторые их комбинации) и имеют логические столбцы для типа предпочтений, установленных в нем. Таким образом, все предпочтения, которые вам понадобятся для каждой области сайта, будут находиться в одной и той же таблице или не более чем в двух или трех таблицах, что позволит относительно легко получить информацию обратно. Это единственное место, где дизайн имеет решающее значение для производительности (вы будете постоянно искать предпочтения, так что даже миллисекунды будут считаться), поэтому вам действительно следует сначала рассмотреть производительность в своем проекте. Здесь это гораздо важнее, чем любое желание сделать это объектно-ориентированным или создать меньше работы для разработчика при настройке.

Answer 3

Есть определенные предпочтения, которые пользователь предпочитает больше (все животные равны, но некоторые более равны, чем другие). Они должны быть специально оптимизированы для поиска и применения в интерфейсе при входе в систему. По мере уменьшения глубины предпочтения они могут быть агрегированы с использованием любых критериев и сохранены в виде отдельных столбцов, возможно, в виде массивов (например, столбец настроек шрифта включает тип шрифта, размер и цвет и ссылается на таблицу шрифтов). Также внесите в указатель интенсивно используемые столбцы, используя инструментальные средства db, и измените дизайн, чтобы разделить агрегированные столбцы, чтобы можно было определить, какой элемент в агрегации находится под повышенным спросом.

В целом пользовательские предпочтения, как правило, очень статичны (то есть являются привычкой), не путайте пользовательские данные, которые более изменчивы, с предпочтениями.

Answer 4

Другой вариант, который вы могли бы сделать (если вам не нужны ваши элементы, хранящиеся в БД, например, для проверки статистики для вещей (кто что делает и т. Д.)), Вы можете просто поместить все их настройки в файл cookie и сохранить это на их машине.

Конечно, с куки приходит все предостережения от использования куки. но просто другая идея ...

Answer 5

Если вам не нужно искать предпочтения, вы всегда можете сохранить предпочтения в формате XML и сохранить их в столбце «Предпочтения». Должно облегчить добавление новых настроек в будущем;)

Answer 6

Если предположить, что пользовательские данные уже сохранены в базе данных, то я не вижу реальной проблемы, когда они хранятся в одной строке, особенно если вам может потребоваться выполнить запросы, основанные на данных, т.е. выбрать всех пользователей с предпочтением A ИЛИ B и т. д.

Я бы, однако, загрузил его в класс и сохранил этот класс с помощью какого-то механизма кэширования.

Answer 7

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