Дизайн таблицы для системных настроек, лучшая модель - PullRequest
5 голосов
/ 08 марта 2010

Кто-то предложил переместить таблицу, полную настроек, где каждый столбец - это имя (или тип) настройки, а строки - это клиенты и их соответствующие настройки для каждой настройки.

ID | IsAdmin | ImagePath
------------------------------
12 | 1 | \ Путь \ к \ изображений
34 | 0 | \ Путь \ к \ изображения

Недостатком этого является то, что каждый раз, когда нам нужно новое имя параметра (или тип), мы изменяем таблицу (через sql) и добавляем новое имя (тип) параметра / столбца. Затем обновите строки (чтобы у каждого клиента теперь было значение для этого параметра).

Новое предложение по оформлению стола. Предложение состоит в том, чтобы иметь столбец для настройки имени и еще один столбец для настройки.
ID | SettingName | SettingValue
----------------------------
12 | IsAdmin | 1
12 | ImagePath | \ Путь \ к \ изображений
34 | IsAdmin | 0
34 | ImagePath | \ Путь \ к \ изображения

Они отметили, что добавление нового параметра было так же просто, как простой оператор вставки в строку, без добавления столбца.

Но что-то не так во втором дизайне, выглядит плохо, но я не могу выдвинуть никаких аргументов против этого. Я не прав?

Ответы [ 3 ]

2 голосов
/ 08 марта 2010

Это вариант схемы " Значение атрибута объекта " ( Джоэл и случайный вопрос SO )

У него есть несколько плюсов и больше минусов, и он почти наверняка закончится слезами.

1 голос
/ 08 марта 2010

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

  • Держите ваши ключевые строки статичными, никогда не переименовывайте.
  • Убедитесь, что при каждом получении словаря настроек вы обновляете его до последней версии (обычно добавляя ключи и устанавливая значения по умолчанию / предлагая пользователю).
  • Сложно смешивать строки и, например, десятичные данные, вам нужно либо выбрать один, либо указать несколько столбцов, которые можно обнулять, чтобы хранить данные в соответствующем формате. Держите эти метаданные где-нибудь рядом.
  • Код, который работает со словарем, должен обернуть его строго типизированным способом, никогда не отображать его как реальный словарь (в смысле структуры данных), вместо этого предоставить класс.
0 голосов
/ 08 марта 2010

Использование имен столбцов для различения настроек, как правило, ужасная идея. Сущность, с которой вы имеете дело, является НАСТРОЙКОЙ и имеет атрибуты ИМЯ и ЗНАЧЕНИЕ. Если вам нужно использовать одно и то же имя в разных контекстах, сделайте SETTING иерархическим, то есть каждый параметр, кроме корневого, получает родительский элемент. В этом случае ваши клиенты могут иметь корень в качестве родителя, и путь для каждого клиента будет одинаковым для каждого параметра. Вы можете использовать разные столбцы для дополнительных типов данных, если хотите.

...