我正在开发一个SaaS应用程序，其中每个客户将根据购买的版本，购买的其他功能而具有不同的配置。例如，一个客户可能有3个自定义报告的限制。

显然我想将此配置存储在数据库中，但是我不确定最好的方法。我们希望将来能够添加其他功能，而无需更改数据库架构，因此在每个配置选项中包含一列的单个表是不明智的。

可能的选项是每个客户一个表，每个客户都有一个XML字段，其中包含该客户的整个配置，但是当XML模式更改为添加其他功能时，该字段会增加复杂性。

我们可以使用带有键值对的表，并将所有配置设置存储为字符串，然后解析为正确的数据类型，但这似乎有点费解，对于字符串配置选项，整数配置选项，还有一个单独的表，等等。

人们正在使用的这种情况是否有很好的模式？

解决方案

键值对表(但所有内容都存储为字符串)和另一列(如有必要)存储该值应该转换为哪种类型。

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

如果不能将值强制转换为类型，那么我们就知道这是一个错误配置并且没有歧义。

如果数据库是SQL Server 2005+，则键/值表可以将SQLVARIANT数据类型用于value字段，并在第三列中存储需要强制转换为使用的数据类型。

这样，我们就可以在同一个字段中插入大小不同的数字和文本值。

我认为这将取决于产品如何销售给客户。

如果仅以包装形式出售...

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

这对我来说最有意义。

实际上，我看不到这里需要不同的配置。我们需要的是授权级别和适当的用户界面，以不显示用户未付费的功能。

对于此类应用程序而言，一个很好的授权数据模型将是基于角色的访问控制(RBAC)。 Google是朋友。

我们为什么如此害怕架构更改？更改应用程序时，毫无疑问，我们将需要其他配置数据。这将导致其他架构更改，那么为什么要害怕呢？

模式更改是我们应该能够容忍的，并应包含在开发，测试和发布过程中，并可以在将来用于设计更改中。

模式发生变化；习惯它 ：)