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 回答