会员订阅付款的 SQL 表设计帮助
我正在为高尔夫俱乐部规划/设计 MSSQL 数据库。 我有下表:
成员 – 标准联系信息 会员类型 - 正式会员、初级会员、60 岁以上会员等。 付款方式——现金、定期订单、支票等。
我正在努力解决的表格设计之一是付款。每年 1 月,订阅金额都会发生变化,例如,2010 年,正式会员订阅费为全年 1000 英镑,因此,如果会员 A 是“正式会员”,他可以一次性支付 1000 英镑,也可以在 10 个月内分期付款。
这部分不是问题。我可以有一个包含 PaymentID、MemberID、Date、PaymentAmount 的付款表,这可以告诉我该会员迄今为止已支付了多少金额以及未付款金额。
对我来说,问题是 2011 年 1 月,正式会员订阅可能会增加到 1100 英镑,这在尝试进行计算时会产生问题。理论上,我需要存档 2010 年的付款并从 2011 年重新开始 - 我不想这样做,因为我想显示该会员曾经支付的每笔付款的历史记录。我欢迎任何有关此场景最有效的表格设计的建议。
I am planning/designing a MSSQL database for a golf club.
I have the following tables:
Members – standard contact information
MembershipTypes - Full, Junior, Over 60’s etc..
PaymentMethods – Cash, Standing Order, Cheque etc..
One of the table designs I am struggling with is payments. Each January the subscription amount will change, for example in 2010 the Full Members subscription is £1000 for the year, so if Member A is a “Full Member” he can pay the £1000 upfront in one payment or instalments over 10 months.
This part is not a problem. I could have a payments table with PaymentID, MemberID, Date, PaymentAmount and this could tell me how much the member has paid to date and how much is outstanding.
The issue for me is in January 2011 the Full Members subscription could increase to £1100 which would create a problem when trying to do calculations. In theory I would need to archive the 2010 payments and start fresh for 2011 – I don’t want to do this as I would like to show a history of every single payment the member has ever made. I welcome any suggestions for the most efficient table design for this scenario.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我相信您需要会员级别的可变订阅金额。例如,如果我注册并且您为我帮助您设计提供折扣,则您向我收取的金额应位于会员级别以及订阅日期,以便您知道每月或一次性收取多少费用。当我的订阅即将到期(无论是滑动还是静态)时,我应该按基本费率(即新费率)付费。此时的数学非常简单,因为您知道我什么时候注册的、到目前为止我已经支付了多少钱以及我欠多少钱(按比例分配或滑动)。
这是一个基本示例:
未经测试的查询,但非常接近:
I believe you need a variable subscription amount at the member level. For example, if I sign up and you give me a discount for helping you with the design, the amount you charge me should be located at the member level along with a subscription date so you know how much to collect, monthly or all at once. When my subscription is about to expire (either sliding or static), I should be charged the base rate which would be the new rate. The math is quite simple at this point because you know when I signed up, how much I've paid to date and how much I owe (prorated or sliding).
Here's a basic example:
Untested queries, but very close:
我认为您需要创建一个名为“会员费用”的表,其中每年的会员费用用唯一的 ID 记录,该 ID 规定了每种类型的会员每年必须支付的费用。这应该使您能够允许会员针对特定“产品”进行付款。
I'm thinking that you need to create a table called membership costs where the membership fees per year are recorded with a unique ID that stipulates the fee that each type of member must pay per year. This should enable you to allow members to make payments in reference to a particular "product".