托管计费/订阅系统的设计数据库答案

【问题标题】：Design Database for Hosting Billing/Subscription System托管计费/订阅系统的设计数据库
【发布时间】：2014-05-17 03:06:47
【问题描述】：

我正在为托管应用程序创建一个计费系统..

所以，基本上，

用户可以购买主机和域名，或者可以购买云并在那里创建自己的服务器。

也应该有插件。

插件可以应用于任何类型的包。因此，用户可以将“服务器管理”从云端添加到服务器。或者为整个云添加“云管理”..

托管和域是预付费的东西。所以用户提前付款。但是云 - 用户在云中注册，然后可以创建服务器 - 然后我们每月为他们开具一次云使用发票（不是针对每台服务器）。

您能在这里评论一下它有什么不好的地方以及如何改进它吗？

要提一下：云和插件按使用时间付费，所以如果插件在 2 天后处于活动状态，然后用户将其删除 - 那么我们应该只为用户开 2 天的发票..

【问题讨论】：

请您先解释一下为什么您认为设计不好？
云是问题.. 价格未知。这是一个动态值，每秒都在变化。因此，我要么必须每小时/每天获取统计数据才能获得价格，要么在开具发票时获取所需的价格。这意味着在orders 云/服务器的价格将始终为 0（因为我会生成经常性价格提前）。不知道如何改进它

【解决方案1】：

我可以立即看到的一个问题是插件。用户和他/她选择的插件之间没有联系。如果您想知道用户选择了哪些插件，您似乎无法满足该查询。

我在您的设计中也看不到包和插件之间的一对多关系的概念。一个包可能有多个插件，您需要对其进行建模。

这将我带到我的下一点，即订单表。那里只有 packageId。但是您不会捕获固定到该软件包的插件。这是一个缺陷，因为您将无法判断哪个客户订购了特定的附加组件到包或反向查询。所以你需要重新建模你设计的那部分。

另一个问题：发票通常具有与其关联的 orderId。您的发票表中不存在 orderId。

如果您更新模型，我稍后会再次审核。希望对您有所帮助。

【讨论】：

感谢您的回答。插件 - 当用户选择和插件时，我希望它作为所选包的子包添加到包表中。这就是没有链接的原因，它只是将parent_id 设置为父包的子包。然后使用订单 - 因为插件将是一个常规包 - 我可以将其添加为单独的订单行。不好吗？
"如果您想知道用户选择了哪些插件，您似乎无法满足该查询。" - 我可以查询packages 表：从type='addon' and user_id=123/* and parent_id=456*/的包中选择
是的，但这不会告诉您客户选择了哪种类型的插件。没有插件 ID 关联。
通常，这不是好的数据库设计。在表示这样的一对多关系时，我们会引用其他表的外键。
对于云 - 我也想将云凭据保存在 data 列中。有更好的主意吗？我知道我可以为插件 ID 添加一个单独的列，但是它会丢失包的泛化.. 所以.. addon_id 用于插件，然后是用户/密码用于云.. 然后谁知道其他包是什么..