Question

I’m working on a SaaS application where each customer will have different configurations depending on the edition they have purchased, additional features they have purchased, etc. For example, a customer might have a limit of 3 custom reports.

Obviously I want to store this configuration in the database, but I am unsure of the best approach. We want to be able to add additional features in the future without requiring a change to the database schema, so a single table with a column per configuration option isn’t sensible.

Possible options are a table with one entry per customer, with an XML field containing the entire configuration for that customer, but that adds complexity when the XML schema changes to add additional features.

We could use a table with key value pairs, and store all configuration settings as strings and then parse to the correct data type, but that seems a bit of a cludge, as does having a seperate table for string config options, integer config options, etc.

Is there a good pattern for this type of scenario which people are using?

Answer 1

I think this would depend on how your product was sold to the customer.

If you only sell it in packages…

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 

I would think it would be easier to setup a table of those packages and link to that.

If you sell each module by itself with variations…

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

Then I would —

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. 

CUSTOMERS

customer_id (pk) 

MODULES

module_id (pk) module_name (reports!) 

CUSTOMER_MODULES

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

This makes the most sense to me.