我的超级简单推荐计划（计划中的）有漏洞吗？
我正计划为我最近的初创公司编写一个推荐计划。目的是吸引现有会员招募新会员。该网站的每个会员都将拥有一个推荐代码和访问材料以帮助宣传该服务。
当新客户使用当前会员的推荐代码注册并付款时，进行推荐的会员将收到一次性付款（大约是客户开始时支付的费用的 50%）。
为此，我将在用户个人资料表中添加 1 个字段 - 来存储他们的（注册时生成的）推荐代码。
然后，我将设置一个推荐表来存储推荐（日期、推荐代码、新客户 ID）。每个月底，我都会在推荐表上生成一份报告，说明谁获得报酬以及获得多少报酬。我将使用 PayPal 进行付款。
每年我都会出于税收目的运行一份报告，然后擦除数据库（以保持较小的大小）。
这个看起来紧吗？是否有我未列出但应该使用的表字段/数据？看起来很难利用这个设置吗？
I'm planning on writing a referral program for my recent startup. The goal is to entice the current members to recruit new members. Every member of the site will have a referral code and access to materials to help advertise the service.
When a new client signs up and pays, using a current member's referral code, the member who made the referral will receive a one-time payment (roughly 50% of what the client pays at start).
To do this, I'll add 1 field in the user profile table - to store their (generated at signup) referral code.
Then, I'll setup a referrals table to store referrals (date, referral code, new client id). At the end of each month, I'll run a report on the referral table that says who gets paid and how much. Using PayPal I'll make the payments.
Annually I'll run a report for tax purposes and then wipe the DB (to keep size low).
Does this look tight? Are there table fields/data that I didn't list, but should be using? Does it look like it would be hard to exploit this setup?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不要擦除数据库。当涉及到任何涉及金钱交易的事情时，您需要记录所有内容 - 更新、编辑、更改、插入、删除，并且会出现退款、Paypal API 失败、数据库连接不起作用等情况。
如果您擦除推荐数据库，则无法回溯。
Do not wipe the DB. When it comes to anything that deals with transactions of money, you need to log everything - updates, edits, changes, insertion, deletion, and there will be charge-backs, the Paypal API failing, database connections not working and so on.
If you do the wipe the DB of referrals, you can't backtrack.
ExtraKun 的观点很好，您可能还需要它用于税务目的。
如果您想保持主数据库较小，则 EOY（年终）报告将数据存档在存档表中，这样您就可以提供历史查找功能（在以后有需要时）。
Good point by ExtraKun, you may also need it for tax purposes.
If you want to keep the primary db small, post EOY (End of Year) report archive the data in archiving tables, that way you can provide historic look up functionality (at a later date when and if it become neccessary).