Хранение очень Детализированных пользовательских настроек
@Cebjyre. IDE или Руководитель предприятия или Studio управления лучше, чем что-нибудь, что я видел до сих пор для MySQL. Я говорю 'легче использовать', потому что я могу сделать много вещей в MSSQL, где MySQL не имеет никаких дубликатов. В MySQL я понятия не имею, как настроить запросы путем простого рассмотрения плана запросов или рассмотрения статистики. Индексный настраивающий мастер в MSSQL берет на себя большую часть работы предположения, что индексы пропускают или неуместные.
Один недостаток MySQL нет никакого макс. размера для базы данных. База данных просто увеличилась бы в размере, пока это не заполняет диск. Вообразите, совместно использует ли этот диск базы данных с другими пользователями, и внезапно все их запросы перестали работать, потому что их базы данных не могут вырасти. Я сообщил об этой проблеме к MySQL давным-давно. Я не думаю, что это фиксируется все же.
7 ответов
Сериализация большого количества данных является подходящим вариантом, но не по соображениям производительности, а потому, что это аспект системы, который, вероятно, претерпит огромное количество изменений. Вы не хотите изменять схему своей БД только потому, что теперь вам нужно разрешить предпочтение включать расширенный режим на какой-то странице или в чем-то подобном.
Модель сущность-атрибут-значение, упоминаемая в HLGEM, соответствует этому из " легко развить "перспективу, но, по ее словам, это будет иметь очень низкую производительность.
От сериализованных объектов вы бы отказались, так это возможность напрямую запрашивать базу данных для пользователей, соответствующих определенному шаблону (возможно, вы отслеживаете ошибка, которая может возникнуть только при некоторой комбинации настроек, и вы хотите узнать, есть ли у вас пользователи с этой комбинацией).
что бы вы ни делали, избегайте использования для этого структуры сущности-атрибута-значения ( http://en.wikipedia.org/wiki/Entity-Attribute-Value_model ), если только вам нужна очень плохо работающая система. Вызов одной таблицы с 50 столбцами будет намного быстрее, чем вызов одной таблицы, к которой вам нужно присоединиться до 50 раз, чтобы получить всю необходимую информацию.
Я бы сделал связанную таблицу для каждой общей группы предпочтений (предпочтения входа в систему, общие предпочтения сайта, предпочтения конкретной страницы или функций), основываясь на том, как вы собираетесь запрашивать предпочтения (если вы хотите вернуть все назад при входе в систему Vice вытаскивает те, которые необходимы для всего сайта при входе в систему, и те, которые необходимы только для специализированных областей, когда пользователь нажимает на них, поэтому некоторые их комбинации) и имеют логические столбцы для типа предпочтений, установленных в этом. Таким образом, все предпочтения, которые вам понадобятся для каждой области сайта, будут в одной таблице или максимум в двух или трех таблицах, что позволит относительно легко получить обратно информацию. Это то место, где дизайн имеет решающее значение для производительности (вы все время будете искать предпочтения, поэтому даже миллисекунды считаются), поэтому вам действительно следует в первую очередь учитывать производительность в своем дизайне. Здесь гораздо важнее, чем любое желание сделать это объектно-ориентированным или создать меньше работы для разработчика при настройке.
так что вам действительно стоит в первую очередь подумать о производительности. Здесь гораздо важнее, чем любое желание сделать это объектно-ориентированным или создать меньше работы для разработчика при настройке. так что вам действительно стоит в первую очередь подумать о производительности. Здесь гораздо важнее, чем любое желание сделать это объектно-ориентированным или создать меньше работы для разработчика при настройке.Я не знаю, буду ли я вообще хранить такую информацию, как настройки пользователя, в базе данных. Кажется, вы захотите просмотреть многие (если не все) пользовательские настройки, как только пользователь войдет в систему; если вы в конечном итоге выполните кучу запросов к базе данных, ваша система будет работать довольно медленно. Вместо этого я бы рекомендовал сохранить ВСЕ пользовательские настройки в одном файле (или в одной записи где-нибудь), проглотить их сразу и кэшировать, как только пользователь войдет в систему.
Если вам не нужно искать предпочтения, вы всегда можете сохранить предпочтения как XML и сохранить его в столбце «Предпочтения». Должен упростить добавление новых предпочтений в будущем;)
Другой вариант, который вы могли бы сделать (если вам не нужны ваши элементы, хранящиеся в БД, например, для проверки статистики на предмет (кто что делает и т. Д.)), Вы можете просто поместить все свои настройки в файле cookie и сохраните его на своей машине.
Конечно, с файлами cookie есть все предостережения при использовании файлов cookie. но это еще одна идея ...
Предполагая, что пользовательские данные уже хранятся в базе данных, я не вижу реальной проблемы с сохранением их всех в одной строке, особенно если вам может потребоваться выполнять запросы на основе данных, т.е. выбрать всех пользователей с предпочтением A ИЛИ B и т. д.
Я бы, однако, загрузил его в класс и сохранил этот класс с помощью какого-то механизма кэширования.
Есть определенные предпочтения, которые пользователь предпочитает больше (все животные равны, но некоторые более равны, чем другие). Они должны быть специально оптимизированы для поиска и применения в интерфейсе при входе в систему. По мере уменьшения глубины предпочтений они могут быть агрегированы с использованием любых критериев и сохранены как отдельные столбцы, возможно, в виде массивов (например, столбец предпочтений шрифтов включает тип, размер и цвет шрифта и относится к таблице шрифтов). Также проиндексируйте часто используемые столбцы с помощью инструментов db и измените дизайн для разделения агрегированных столбцов, чтобы вы могли определить, какой элемент в агрегации пользуется большим спросом.
В целом пользовательские предпочтения обычно очень статичны (т. Е. Похожи на привычку) , не путайте пользовательские данные, которые более изменчивы, с настройками.