管理配置数据的最佳方法

我认为这取决于你的产品是如何卖给客户的。

如果你只卖包装的话…

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

客户模块

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

这对我来说最有意义。

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

这种应用程序的一个好的授权数据模型是基于角色的访问控制(RBAC)。谷歌是你的朋友。

为什么你如此害怕模式改变?当您更改应用程序时,无疑需要额外的配置数据。这将导致其他模式更改,那么为什么要害怕呢?

模式变更是您应该能够容忍的事情,应该融入到您的开发、测试和发布过程中,并在将来的设计变更中加以利用。

架构发生更改;习惯它:)

如果数据库是SQL Server 2005+,则键/值表可以将sqlvariant数据类型用于值字段-第三列用于存储要将其强制转换为使用的数据类型。

这样,您就可以在同一字段中插入不同大小的数字和文本值。

键值对表,但与所有内容一起存储为一个字符串,并与另一列(如果需要)一起声明应将值强制转换为哪种类型。

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

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