推荐数据库架构

Question

我正在使用现在典型的“推荐”系统编写一个新的{每月|每年}付费网站：当新用户注册时，他们可以指定其他用户的{用户名|推荐代码}（如果他们来自一个特殊的 URL），这将导致推荐人获得新用户支付的一定比例的收入。

在重新发明轮子之前，我想知道你们中是否有人有在关系数据库中存储此类数据的经验。 目前我正在使用 MySQL，但我相信任何好的解决方案都应该能够轻松适应任何 RDBMS，对吗？

我希望支持以下功能：

• 在线计费系统 - 每张发票支付后，就会计算推荐收入，并且他们将能够兑现。 当然，这包括在线浏览发票/付款的可能性。

• 付费选项各不相同 - 它们的性质和成本不同（有时会有所不同），因此应根据每张最终发票计算佣金。

• 跟踪推荐（用户之间的关系、推荐日期以及任何其他有用信息 - 有什么想法吗？）

• 一种访问历史推荐数据（已支付多少）或应计费用的简单方法佣金。

• 将来，我可能会提出用累积现金换取续订（涵盖整个新订阅或仅部分新订阅，如果需要，必须支付差额）

• 多个级别 - 我正在考虑支付大约 10% 的直接推荐收入 + 2% 的下一个级别，但这可能会在未来发生变化（添加更多级别，更改百分比），所以我应该能够存储历史数据。

请注意，我不打算在任何其他项目中使用它，所以我不担心它是“即插即用”的。

您做过类似要求的工作吗？ 如果是这样，你是如何处理所有这些事情的？ 您会推荐任何特定的数据库架构吗？ 为什么？

我是否缺少任何东西可以帮助使其成为更灵活的实施？

Answer 1

令人惊奇的是，有一个数据库架构库。 虽然我看不到推荐的具体内容，但可能有一些相关的内容。 至少（希望）你应该能够得到一些想法。