Дизайн таблицы для SystemSettings, лучшей модели
Кто-то предложил переместить таблицу, полную настроек, где каждый столбец является именем установки (или тип), и строки являются клиентами и их соответствующими настройками для каждой установки.
Идентификатор | IsAdmin | ImagePath
------------------------------
12 | 1 | \path\to\images
34 | 0 | \path\to\images
Оборотная сторона к этому является каждым разом, когда мы хотим новое имя установки (или тип), мы изменяем таблицу (через sql) и добавляем новое (столбец), определяющий имя. Затем обновите строки (так, чтобы у каждого клиента теперь было значение для той установки).
Новая таблица разрабатывает предложение. Предложение состоит в том, чтобы иметь столбец для того, чтобы определить имя и другой столбец для установки.
Идентификатор | SettingName | SettingValue
----------------------------
12 | IsAdmin | 1
12 | ImagePath | \path\to\images
34 | IsAdmin | 0
34 | ImagePath | \path\to\images
Мнение, которое они высказали, было то, что добавление новой установки было так же легко как простой оператор вставки к строке, никакому добавленному столбцу.
Но что-то не чувствует себя хорошо о втором дизайне, он выглядит плохо, но я не могу придумать аргументы против него.Я неправ?
3 ответа
Это вариант схемы « Значение атрибута объекта » ( Джоэл и случайный вопрос SO )
Он имеет несколько плюсов и многое другое минусы, и это в значительной степени гарантированно закончится слезами.
Использование имен столбцов для различения настроек обычно является ужасной идеей. Сущность, с которой вы имеете дело, - это НАСТРОЙКА, и у нее есть атрибуты ИМЯ и ВАЛЮТА. Если вам нужно использовать одно и то же имя в разных контекстах, сделайте SETTING иерархическим, т.е. у каждой настройки, кроме корневой, есть родитель. Тогда ваши клиенты могут иметь корень в качестве своего родителя, и путь под каждым клиентом будет одинаковым для каждой настройки. При желании вы можете использовать различные столбцы для дополнительных типов данных.
Второй подход на самом деле напоминает словарь. Я обнаружил, что это более удобный выбор для приложения, над которым я работаю, по причинам, о которых вы упомянули.У этого подхода есть несколько предостережений, поэтому вы должны быть осторожны с ними:
- Держите ваши ключевые строки статичными, никогда не переименовывайте.
- Убедитесь, что каждый раз при получении словаря настроек вы обновляете его до последней версии (обычно путем добавления ключей и установки значений по умолчанию / запроса пользователя).
- Сложно смешать строку и, например, десятичных данных, вам нужно будет либо выбрать один, либо предоставить несколько столбцов, допускающих значение NULL, чтобы вы могли хранить данные в соответствующем формате. Храните эти метаданные где-нибудь.
- Код, который имеет дело со словарем, должен оборачивать его строго типизированным образом, никогда не раскрывать его как настоящий словарь (в смысле структуры данных), вместо этого предоставлять класс.