3

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

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

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

我们可以使用带有键值对的表,并将所有配置设置存储为字符串,然后解析为正确的数据类型,但这似乎有点混乱,就像为字符串配置选项、整数配置选项提供单独的表一样,等等

人们正在使用的这种场景是否有一个好的模式?

4

5 回答 5

3

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

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

于 2008-10-11T19:52:08.013 回答
2

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

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

于 2008-09-29T20:58:37.340 回答
2

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

如果你只卖包装...

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

这对我来说最有意义。

于 2008-10-01T23:22:43.437 回答
2

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

架构更改是您应该能够容忍的,将其纳入您的开发、测试和发布过程,并在未来的设计更改中加以利用。

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

于 2008-11-02T13:31:55.140 回答
1

键值对表,但所有内容都存储为字符串,并使用另一列(如有必要)说明应将值转换为哪种类型。

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

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

于 2008-09-29T11:33:00.803 回答