Блог

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

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

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

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

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

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

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

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

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

 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?)
 

Для меня это имеет наибольший смысл.

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

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

Происходят изменения схемы; привыкайте к этому 🙂

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

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

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

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

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