【问题标题】:Are there holes in my super simple referral program (planned)?我的超级简单推荐计划(计划中)有漏洞吗?
【发布时间】:2010-02-04 06:57:16
【问题描述】:

我正计划为我最近的创业公司编写推荐计划。目标是吸引现有成员招募新成员。该网站的每个成员都将拥有一个推荐代码和访问材料以帮助宣传该服务。

当新客户注册并使用当前会员的推荐代码付款时,进行推荐的会员将收到一次性付款(大约是客户开始时付款的 50%)。

为此,我将在用户个人资料表中添加 1 个字段 - 以存储他们(在注册时生成的)推荐代码。

然后,我将设置一个推荐表来存储推荐(日期、推荐代码、新客户 ID)。每个月末,我都会在推荐表上生成一份报告,说明谁获得报酬以及获得多少报酬。我会使用 PayPal 付款。

每年我都会出于税收目的生成一份报告,然后擦除数据库(以保持较小的大小)。

这看起来很紧吗?是否有我没有列出但应该使用的表字段/数据?看起来很难利用这个设置吗?

【问题讨论】:

    标签: c# referrals


    【解决方案1】:

    不要擦除数据库。当涉及到任何涉及金钱交易的事情时,您需要记录所有内容——更新、编辑、更改、插入、删除,并且会有退款、Paypal API 失败、数据库连接不工作等等。

    如果您擦除推荐数据库,则无法回溯。

    【讨论】:

    • 这很好。一开始,将手动进行 PayPal 付款。所以API中没有失败。不会有任何更新,推荐要么发生,要么没有。我真的只需要分贝知道该付钱给谁。在年底,我会创建一份报告、打印、扫描并保存在保险箱中。觉得这样可以吗?
    • 另外,从不进行更新。仅使用插入语句(使用更新触发器执行此操作)并使用 idIsActive 字段或其他内容来跟踪最新版本。
    • 我建议您考虑在您的桌子上使用触发器。它们非常适合记录此类情况。
    【解决方案2】:

    ExtraKun 的好点子,您可能还需要它用于税收目的。

    如果您想保持较小的主数据库,请发布 EOY(年终)报告将数据归档到归档表中,这样您就可以提供历史查询功能(在以后需要时)。

    【讨论】:

    • 嗯...我想我解释得不够清楚。数据库表只会存储进行了推荐的事实。实际的货币流程都在 PayPal 下。交易证明将在 PayPal 下。
    猜你喜欢
    • 1970-01-01
    • 2011-01-31
    • 1970-01-01
    • 1970-01-01
    • 2011-08-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多