Лучший способ управлять данными конфигурации

Question

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

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

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

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

Есть ли хороший пример для этого типа сценария, который используют люди?

Answer 1

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

Хорошей моделью данных авторизации для такого приложения будет управление доступом на основе ролей (RBAC). Google твой друг.

Answer 2

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

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

происходят изменения схемы; привыкнуть к нему:)

Answer 3

Если ваша база данных - SQL Server 2005+, ваша таблица ключ / значение может использовать тип данных SQLVARIANT для поля значения - с третьим столбцом для хранения типа данных, к которому вам нужно привести его для использования.

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

Answer 4

Я думаю, это будет зависеть от того, как ваш продукт был продан покупателю.

Если вы продаете его только в упаковках ...

PACKAGE 1 -> 3 reports, date entry, some other stuff.
PACKAGE 2 -> 6 reports, more stuff
PACKAGE 3 -> 12 reports, almost all the stuff
UBER PACKAGE -> everything

Я думаю, что было бы проще настроить таблицу этих пакетов и ссылку на нее.

Если вы продаете каждый модуль отдельно с вариациями ...

Customer wants 4 reports a week with an additional report every other tuesday if it's a full moon.

Тогда я бы -

Create a table with all the product features.
Create a link table for customers and the features they want.
In that link table add an additional field for modification if needed.

КЛИЕНТАМ

customer_id (pk)

МОДУЛИ

module_id (pk)
module_name (reports!)

CUSTOMER_MODULES

module_id (pk) (fk -> modules)
customer_id (pk) (fk -> customers)
customization (configuration file or somesuch?)

Это наиболее логично для меня.

Answer 5

Таблица пар ключ-значение, но со всем хранится в виде строки и с другим столбцом (при необходимости), в котором указывается тип, к которому следует привести значение.

CREATE TABLE configKVP(clientId int, key varchar, value varchar, type varchar)

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