付费订阅网站的最佳表格设计是什么？
我的网站将提供每月付费订阅访问，我正在尝试考虑设置桌子的最佳方式。如果用户希望升级到高级服务，可以选择通过贝宝付款。我假设如果用户选择停止使用服务，他们的帐户将被限制为有限的免费访问版本。
我在想我可以将其维护在一个表中作为用户详细信息，即：
USERS
ID| NAME| MEMBERSHIP_TYPE| LAST_PAYMENT_DATE| ACTIVE_TILL| TRANSACTION_ID
我是否需要将其分成两个不同的表
USERS
ID| NAME
MEMBERSHIPS
USER_ID|MEMBERSHIP_TYPE|LAST_PAYMENT_DATE|ACTIVE_TILL|TRANSACTION_ID
并将付款历史记录存储在第三个表中。我将在这里使用定期计费。
my site would offer paid monthly subscription access and I was trying to contemplate the best way to set up my tables. Users can opt to pay by paypal if they wish to upgrade to premium services. I'm assuming that should a user choose to discontinue with the services their account would be restricted to a limited free access version.
I'm thinking that can I maintain this in a single table as the user details i.e:
USERS
ID| NAME| MEMBERSHIP_TYPE| LAST_PAYMENT_DATE| ACTIVE_TILL| TRANSACTION_ID
Of do I need to separate it into two different tables
USERS
ID| NAME
MEMBERSHIPS
USER_ID|MEMBERSHIP_TYPE|LAST_PAYMENT_DATE|ACTIVE_TILL|TRANSACTION_ID
And store the history of payments in a third table. I would be using recurring billing here.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您希望将付款交易与用户列表分开，因为您希望能够查看续订历史记录。您可能会有用户付款、请求退款、再次付款、会员资格到期，然后续订，等等。如果没有保留此活动历史记录的事务表，您可能会发现自己无法解决客户服务或会计问题。
假设您只有一种付费会员资格（这可能不是一个未来安全的假设），并假设您采取了适当的程序控制，例如使用存储过程或触发器来同步事务包装器中的数据，您可以将会员资格类型非规范化并直到您的 USERS 表中的日期为止处于活动状态。这种类型的冗余可能有助于您的操作性能，但如果您允许冗余数据不同步，也可能存在很大的风险。我建议在没有冗余的情况下尝试它，然后在求助于在 USERS 中使用非规范化字段之前看看是否存在实际性能问题。
You want to segregate payment transactions from your user list because you will want to be able to see the history of renewals. You might have users that pay, request a refund, pay again, have their membership expire, and then renew - and so forth. Without keeping a transaction table that maintains the history of this activity, you could find yourself being unable to untangle a customer service or accounting problem.
Assuming you only have one kind of paid membership (which may not be a future-safe assumption) and assuming you put the proper procedural controls in place, like using stored procs or triggers to synchronize data within transactional wrappers, you could denormalize membership type and active until date in your USERS table. This type of redundancy might help your operational performance but it is also potentially very risky if you allow the redundant data to get out of sync. I'd recommend trying it without the redundancy and then see if you have a practical performance issue before resorting to using denormalized fields in USERS.