我正在设计一个支付用户完成某些任务的网络服务。例如，如果用户点击某个链接，则会向其帐户支付0.10美元的费用。用户每天最多可执行20次这些任务中的任何一项。为了让用户请求向他们支付资金，他们必须拥有5美元的帐户余额。
我正在尝试确定跟踪交易和帐户的最佳方式。我的设计目前看起来如下：
Accounts
---------
| account_id | member_id | balance |
-------------------------------------
| 1 | 1 | 497.8500 | -- System Account
| 2 | 5 | 2.1500 |
Transactions
------------
| transaction_id | account_id | type_id | task_id | date | amount |
-------------------------------------------------------------------
| 1 | 1 | Debit | 1 | date | -1.10 |
| 2 | 2 | Credit | 1 | date | 1.10 |
| 3 | 1 | Debit | 1 | date | -1.05 |
| 4 | 2 | Credit | 1 | date | 1.05 |
此设计基于复式的会计原则。现在我的困境是：从技术上讲，用户在请求“支付”之前不会支付这笔钱。 “付款”包括用户提交请求，请求被批准，资金从其帐户余额中扣除并通过PayPal发送给他们。所以我的问题是，如果用户尚未请求付款，实际从系统余额中扣除金额是否是一个好主意？他们帐户中的资金可用于资助网站上的其他内容，它也会在30天不活动后到期。
我的想法是保持事务表不变，并使用以下结构设计另一个名为payouts的表
Payouts
-------
| payout_id | account_id | date | amount |
------------------------------------------
| 1 | 2 | date | $2.00 |
但是，我如何在交易表中反映支出？这似乎不完整。
我是否应该将这些任务与交易表分开，并且只有在用户请求支付时才输入交易记录？我不确定我是否会以这种方式失去审核能力。
有没有人有一些见解？
答案 0 :(得分：0)
有关追踪付款的业务要求是什么？
您的公司是否需要将付款跟踪为具有日期，金额等的单独事件（双重录入），或者他们只需要知道请求付款。
如果其中任何一种情况属实，或者很可能，鉴于其他公司的做法（想想合并），附上支付表就像跟踪支付一样。
您是否也会提供有关复式要求的一些细节。我会尝试将业务规则尽可能明确地保留在您的设计中。
希望这会有所帮助。我们可以在评论中继续对话，
答案 1 :(得分：0)
我的簿记技能有限，所以虽然我希望能提供帮助，但我觉得我没有资格给你答案..
因此，虽然我认为您与纯粹的会计模型相当接近，但我认为在这种情况下支出也应该是交易。
如果用户需要从现金添加到其帐户的概述，此列表还应包含付款。如果用户收到5倍的1美元和1次5美元的支付，他的帐户余额最终应为0。
因此，既然您正在进行这两项交易，这意味着实际付款会从其帐户中扣除5美元，但这也需要在某处。所以我觉得一旦付清，应该有一个单独的帐户'付费'。
但是......我的程序员想知道..你真的想要在你的数据库中进行双重记账吗？在实际付款时，您可以在不使用系统帐户的情况下推断出所有数字。
所以你实际上并没有遗漏任何真实信息..如果现金总是来自系统账户，而且用户无法将余额转移到其他账户..
答案 2 :(得分：0)
只需使用其他帐户/分类帐/余额表代码
So on getting the 10c
Your account is - 10c
Their payout account is + 10c
When the balance on their payout account > $5, then can request one.
When they do debit the amount from payout account, credit it to Payoutpending account
When it confirmed debit payout pending and credit payed out.
If it's rejected debit payout pending and credit payout account
哦，你真的需要考虑存储余额，而不是计算和报告它，你会得到正确的混乱。