定期结算数据库设计

Question

我正在编写一个应用程序，它将涉及每月（或每周）固定金额的定期结算，并且可以持续到订阅被取消为止。客户可以提前几个周期支付。 他可以取消订阅，然后在某些无薪期后回来。 我需要系统让我知道一段时间过去了。

所以我烧了如何设计数据库（也许不是一个数据库的问题，而是一个编程）我的大脑，

是否有任何人来这样的应用程序？采取了什么方法？

Answer 1

我认为你已经过度复杂了。

创建表用户：

pk id_user 
nm_user 
fl_status (active, canceled, pendent, etc) 

创建一个表预订一个用户到许多订阅：

pk id_subscription 
fk id_user 
fl_type (maybe there are different subscriptions, with different prices) 
dt_in 
dt_out 

创建一个表支付一个订阅了许多付款：

pk id_payment 
fk id_subscription 
fl_type (card, payment order, something else) 
fl_status (generated, sent, confirmed, canceled because of subscription canceled, canceled because of something else, etc) 
dt_generated 
dt_sent 
dt_confirmed 
dt_canceled 
[I think you will need another fields to follow and confirm the payment, but it depends of your payment model) 

现在您需要构建一些在特定时间每天运行的机器人。

如果您获得所有活动客户和每个客户的最后一笔付款，您将知道是否需要生成新付款（如果最后一笔确认付款比实际日期多出x天）预付费，后付费等）。如果是，则生成新的付款订单。

一个机器人会发送一封电子邮件或其他东西的订单（和标志然后）。

另一个机器人会使用您的付款模式确认付款。

当然，您需要非常好地定义您的模型，因为每个用户状态都需要一个机器人来保存事情，直到它被取消或由于缺少付款而发送给法官。这是一个很多工作要做，但没有什么大不了的。

ps：如果它是一个更复杂的系统，数据库将会持续存在，你将获得所有你需要的信息，你有每个订单的日志，你知道每个订单发生了什么，因为它们有日期和状态。你可以估计一下，你将有多少到期的日期，一天之后支付多少，两天之后等等。

Answer 2

我想你可能会试图让设计变得太聪明，并且过度使用它。如果您考虑业务问题，每个付款间隔实际上都是发票。为什么不只是创建发票表并让计划作业根据每个帐户的周期性以及在该时间间隔内是否处于活动状态以特定间隔插入发票。

通过拥有实际的发票行，您可以获得InvoiceID，您可以在向客户寻求付款时参考并针对每个结算分别跟踪付款状态。

有时候简单是最好的。