Должны ли «системные данные» быть в базе данных?

Question

Я разработал базу данных для приложения, которая содержит пользовательские настройки. Эта база данных будет загружена с несколькими настройками пользователя системы. Они могут меняться от версии к версии. Как мне поступить с обновлением этих настроек?

Решения, которые я придумал:

1. Примените логическое поле 'system' к таблицам настроек и замените все системные настройки при изменении номера версии базы данных. (что очень раздражает при разработке этих настроек, так как вам приходится постоянно стирать базу данных при разработке)
2. Не помещайте системные настройки в базу данных и каким-либо образом объединяйте системные данные с данными из базы данных при их запросе.

В настоящее время я делаю первое, но как-то второе кажется более подходящим. Что я должен делать и как можно легко объединять внешние данные с данными из базы данных при использовании Microsoft Entity Framework?

Answer 1

Поскольку существует большое количество операций, которые вы, возможно, захотите выполнить с данными, выходящими за рамки простого объединения (внутреннее и внешнее объединения, чтобы увидеть, кто соответствует настройкам системы или не приходит в голову), я бы предложил поставить системные данные в той же структуре, что и пользовательские данные.

Это также допускает поведение, такое как ввод значений по умолчанию из системных данных, когда пользователь не имеет определенного значения.

Есть несколько интересных моментов об управлении настройками и переопределениями в этом сообщении в блоге , если у вас есть время, чтобы прочитать что-то довольно долго.

Answer 2

Я не уверен, что это действительно подходит к вашему вопросу, но я подумал, что это было интересное небольшое упражнение с базой данных. Предположим, у вас есть таблица с названием «настройка», как вы предлагаете в # 1:

+------------+--------------+-----------+---------------+
| setting_id | setting_name | is_system | setting_value |
+------------+--------------+-----------+---------------+
|          3 | foo          |         1 | Blue          |
|          4 | foo          |         0 | Red           |
|          5 | bar          |         1 | Green         |
|          6 | baz          |         1 | Yellow        |
|          7 | baz          |         0 | Orange        |
|          8 | quux         |         0 | Purple        |
+------------+--------------+-----------+---------------+

Первичный ключ будет на setting_id, а к столбцам setting_name и is_system (который является логическим) применяется уникальное ограничение.

Чтобы найти все активные в данный момент настройки (при условии, что пользовательские настройки переопределяют системные настройки), следующий запрос выполнит эту работу:

SELECT  setting_name, setting_value
FROM    setting s
WHERE   is_system = (
                SELECT  MIN(is_system)
                FROM    setting si
                WHERE   s.setting_name = si.setting_name
        );

Выполнение запроса дает такой результат:

+--------------+---------------+
| setting_name | setting_value |
+--------------+---------------+
| foo          | Red           |
| bar          | Green         |
| baz          | Orange        |
| quux         | Purple        |
+--------------+---------------+

Таким образом, если пользовательский параметр существует, он выбирается, в противном случае вместо него используется системное значение по умолчанию.

Использование функции MIN() таким способом является своего рода извращенным способом работы с булевыми значениями, но это достаточно просто.

Answer 3

Я не уверен, что вы хотите достичь с 1), но я могу ответить 2).

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

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

Answer 4

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