在数据库中设计每月订阅系统的良好实践 [关闭]

Posted 2023-02-23

【中文标题】在数据库中设计每月订阅系统的良好实践 [关闭]

【英文标题】：Good practices for designing monthly subscription system in database [closed]

【发布时间】：2014-06-23 19:18:48

【问题描述】：

我想知道如何在数据库中设计每月订阅的软件系统。 这些系统在互联网上被广泛使用，虽然我找不到很多关于数据库设计的东西。

就我而言，这些元素（也许还有一些我忘记的元素）必须包括在内：

客户 计划（如“基本”/“高级”）。每个计划都有每月价格和积分数量（例如：基本计划每月提供 30 个积分，高级计划提供无限积分）。 积分是在应用程序中使用的虚拟货币。 订阅/取消订阅 付款（请注意，由于折扣等原因，实际支付的价格可能与计划的基本价格不同） ... ?

除了数据库设计之外，还可能需要设置触发器来执行此操作 (?)。

我的痛点：

我看不出这个的全局设计是什么 哪一个应该是数据库中的一行：month_susbscition（即每个客户每月 1 行）或订阅本身（即每个客户 1 行）？ 您将如何处理每月订阅的自动续订？ 如果您预计使用 Paypal 等服务来处理每月自动付款，您将如何处理付款设计？

注意

我自愿不详细说明我的需求，因为这样，辩论可以保持笼统，对其他人更有用。

感谢您的帮助。

【问题讨论】：

我建议您与您的提供商讨论自动付款的方式，他们可能会为您希望您做什么提供指导。但一般来说，您可以在数据库上创建一个月度作业，该作业创建一个列表，列出在每月续订日期要向谁收费。然后提供商会告诉您如何将该列表发送给他们。

【参考方案1】：

我会使用关系表设计和关系数据库。

我会有一个客户表。

Client
------
Client ID
Client Last Name
Client First name
...

我会有一个订阅表

Subscription
------------
Subscription ID
Client ID
Subscription Purchased Time stamp
Subscription Started Time stamp
Subscription Ends Time stamp

我会有一个采购表

Purchase
--------
Purchase ID
Subscription ID
Payment method
...

现在回答您的问题。您应该一次只问一个问题。

哪一个应该是数据库中的一行：month_subscription（即每个客户每月 1 行）或订阅本身（即每个客户 1 行）？

每个订阅每月一行。

您将如何处理每月订阅的自动续订？

Netflix 只是每个月从我的 PayPal 帐户中扣款。你可以用 PayPal 或信用卡做同样的事情。如果您接受信用卡，则必须与您的银行、信用卡处理商或 PayPal 进行安排。

如果您预计使用 PayPal 等服务来处理自动每月付款，您将如何处理付款设计？

Netflix 只是每个月从我的 PayPal 帐户中扣款。你也可以这样做。

【讨论】：

购买时间和开始时间不一样？

如果您在另一端之前续订或更改订阅。

这是一个有趣的设计，我也是这么想的，但后来我想为什么不合并两个表，订阅和购买呢？我正在使用 NoSQL DB，宁愿做一次提取而不是两次

NoSQL DB 完全是另一回事，不过，它建议能够为大型应用程序使用一致的数据库设计系统。

【参考方案2】：

我会使用这个模型

您的客户

Client
------
Client ID
Name
...

您的计划（您可以根据需要定义新计划）。 如果您想在客户一次性购买 12 个月的情况下提出折扣建议，我会添加一个 Price_per_year（但这只是一个想法）。

Plan
------
Plan ID
Name
Credits_per_month
Price_per_month
(Price_per_year)

您的订阅

Subscriptions
------
Subscription ID
Client ID
Plan ID
Subscription_start_timestamp
Subscription_end_timestamp

考虑到这个模型，我会在每个计划中为每个客户使用 1 行。

当客户订阅“Premium with 1stmonth free！”之类的优惠时，您的数据库将如下所示：

Client
------
ID: 1; LastName: Foo; ...

Plan
------
ID: 1; Name: Premium; Credits: -1 (unlimited); Price_per_month: 30
ID: 2; Name: Premium 1st month offer; Credits: -1; Price_per_month: 0

Subscription
------
ID: 1, Client ID: 1, Plan ID: 2, Start: 2014-05-07 08:00, End: 2014-06-06 07:59
ID: 1, Client ID: 1, Plan ID: 1, Start: 2014-06-07 08:00, End: 9999-12-06 07:59

当客户在 7 月 1 日取消订阅时，仅用月份和年份更新订阅表中的列末尾（因为您已预先设置日期和时间）。

Subscription
------
ID: 1, Client ID: 1, Plan ID: 2, Start: 2014-05-07 08:00, End: 2014-06-06 07:59
ID: 1, Client ID: 1, Plan ID: 1, Start: 2014-06-07 08:00, End: 2014-07-06 07:59

要知道客户是否未取消订阅，您可以使用：

Select Count(client.*) From Client client
Inner Join Subscription sub On sub.client_id = client.id
Where DATE_TODAY Between sub.start And sub.end

确保您不能同时为一个客户订阅 2 个。

这使您可以在您的应用中自动处理每月订阅，而不是使用您的银行/贝宝帐户。

但有些银行为您提供两种服务： - 独特的借记 - 定期借记

第二个允许您处理每月订阅。

【讨论】：

关于年价格，我将其作为不同的计划，不同的选择。

你是对的。年份价格也可以在数据库之外计算。例如Price_per_month * 12 * 0.9，但该选项应出现在subscription 表中。

我不会计算数据库之外的折扣，我会把它作为一个不同的计划并在数据库中保留一个计划的长度。因此，一个计划将是 1 年，每月价格为“standard_price*0.9”，长度为 12（月），或者以天/周/任何您喜欢的形式保留。

但这是一个不同的用例。在这里，我们需要有一个无限的时间框架。我认为实际模式的问题在于您不知道用户是选择每月订阅还是每年订阅。在这种情况下，我会使用您所说的不同计划，但使用类别（每年、每月）而不是长度。

我会在计划中添加总月数之类的内容，然后您可以在插入订阅表时使用它来计算计划的结束日期。通过这种方式，您将知道计划何时结束并需要续订，以便您可以发送提醒进行续订。您还可以进行自动续订，直到收到不同的通知，以及使用此模型设定结束日期的计划..

【参考方案3】：

查看已接受的答案，我将添加另一个表，其中将存储订阅或计划的所有更改或更新以供反向参考。这样一来，您就可以清楚地了解何时以及在什么时期选择了哪些计划。

我会确保订阅表包含变量，这些变量会告诉您它是否处于活动状态、付款日期以及您在日常操作中可能需要的任何其他可能数据。

额外的表格将确保您能够在需要时在任何给定时间重新创建任何订阅。

【讨论】：

你能分享一下那张桌子的设计吗？