我实际上担心设计完美的表来处理交易和佣金。特别是我们真的不希望表格在任何情况下都不同步。
基本上这就像ebay,商家向买家出售,我们从每笔交易中获得佣金。
该应用已使用Codeigniter构建,它具有:
Merchants(id,name,balance)
Transactions(id,merchant_id,buyer_id,amount,transaction_id)
现在还有哪些其他表可以让我们能够获取我们的收入和卖家的收入,以及处理退款的最佳数据库机制是什么?< / p>
我们是否应该为商家的余额制作另一张每张存款的表格,而不是+ balance
行。
答案 0 :(得分:2)
每当您处理任何财务任务时,请始终尽可能多地存储相关信息。
有两种方法可以保持所有表格同步。
数据库级别 - 使用存储过程和触发器等选项
应用程序级别 - 使用事务(innoDB)并确保事务是原子的。 (我建议你这样做)
关于数据库设计 -
向跟踪佣金的commission
添加一列Transactions
。此数据可以在物品定价时预先计算,也可以在交易过程中实时计算。
买方支付product cost + commission
,卖方获得product cost
,您获得commission
。如果你的佣金是一个变量(不是统一费率并且从一个项目到另一个项目而变化),你可以在Items
表中有一个存储它的列。从现在开始,事情应该是微不足道的。您只需维护一个History
表,该表保存与用户相关的事务列表。它看起来像
AccountHistory(id, transaction_type, transaction_id, amount)
你可以将AccountHistory
分成两个 - 一个用于收款,一个用于汇款。
因此,每次交易发生时,都会发生以下情况
Transactions
表。AccountHistory
买家AccountHistory
这一切都应该是原子的。
对于回滚,您可以添加列transaction_type
以区分回滚与正常事务,或者您可以维护一个单独的表。
答案 1 :(得分:0)
我曾经使用过一个数据库,其中设计的金融交易分散在一堆不同的表中,我可以告诉你,将所有交易放在一个表中要好得多。您应该将事务类型添加到事务表(以及事务类型的查找表)。
然后,每笔交易都可以有单独的佣金和卖家产品成本。稍后撤消的交易将以负数形式输入。添加父事务字段对这些类型的事物也很有帮助,这样您就可以轻松识别它正在更改的事务。
构成事务一部分的所有数据条目都应该在存储过程中并具有事务,这样如果插入的一部分失败,则会立即回滚整个事务。这很关键。它需要位于存储过程中,以便没有人(系统dbas除外)可以直接访问存储财务记录的表。
当您开始考虑处理金融交易时,您可以做的最糟糕的事情就是仅为用户界面进行设计。您需要设计您需要的财务报告。您需要咨询将审核您的财务状况的人员,以了解他们需要哪些信息以及他们希望您采取哪些内部控制措施来防止内部和外部欺诈。