管理配置数据的最佳方式

Question

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

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

可能的选项是每个客户有一个条目的表，其中XML字段包含该客户的整个配置，但是当XML架构发生更改以添加其他功能时，这会增加复杂性。

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

人们正在使用这种类型的场景是否有良好的模式？

Answer 1

实际上，我认为这里不需要不同的配置。您需要的是授权级别和适当的用户界面，不显示用户未支付的功能。

此类应用程序的良好授权数据模型将是基于角色的访问控制（RBAC）。谷歌是你的朋友。

Answer 2

如果您的数据库是SQL Server 2005+，则您的键/值表可以使用SQLVARIANT数据类型作为值字段 - 使用第三列存储您需要将其强制使用的数据类型。

这样你就可以直接输入数字＆amp;不同大小的文本值放在同一个字段中。

Answer 3

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

如果你只是以包裹形式出售......

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 4

为什么你这么害怕架构变化？当您更改应用程序时，您无疑将需要其他配置数据。这将需要其他架构更改，所以为什么要害怕？

架构更改是您应该能够容忍的，并入您的开发，测试和发布过程，并在将来利用设计更改。

架构变化发生;习惯了:)）

Answer 5

键值对表，但是所有内容都存储为字符串，另一列（如果需要）说明值应该转换为哪种类型。

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

如果该值无法转换为该类型，那么您知道这是一个配置错误，并且没有歧义。