Пользовательские настройки в SQL Server - PullRequest
1 голос
/ 08 марта 2012

Я пытаюсь разработать эффективную схему базы данных для пользовательских настроек в SQL Server 2008 R2. Проблема здесь в том, что нам нужно несколько уровней детализации, и я не уверен, как это эффективно представить.

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

AccountId int
ModuleId int
FeatureId int
SettingData string

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

Проблема: Многие клиенты имеют доступ ко многим модулям, и эти модули имеют доступ ко многим функциям. Одна учетная запись, вносящая изменения в SettingData, может изменять 4000 записей. По абсолютно понятным причинам это абсолютно ненадежно, и я решил это исправить.

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

Заранее спасибо, любая помощь приветствуется.

1 Ответ

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

Звучит так, как будто настройки в настоящее время могут быть заданы на следующих уровнях:

  • Счет
  • Модуль
  • Feature

Учитывая, что, вероятно, уже есть таблицы, настроенные для каждой из учетных записей, модулей и функций, представляется целесообразным:

  • Удалить существующую таблицу.
  • Установите новое поле для настройки данных для каждой из существующих таблиц Account, Module и Feature.

Поскольку общий принцип заключается в том, что конкретное должно переопределять общее, настройка уровня модуля должна переопределять настройку уровня учетной записи, а настройка уровня функции должна переопределять настройку уровня модуля.

Преимущество этого подхода заключается в том, что при каждом обновлении определенного параметра необходимо будет обновлять только одну запись.

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

...