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

Question

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

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

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

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

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

Answer 1

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

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

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 2

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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