设计应用程序的问题

Question

我有关于设计簿记应用程序的问题。 简而言之，应用程序会记录人员之间分摊的费用。每笔费用都记录为一笔交易，并且该组中的每个人都要从该组中的另一个欠款/获得金钱。

我一直在决定在哪里保存谁欠谁和数据库中的总数。

策略1： 只要保持最近的总数在数据库表是这样的（3个用户）

id user_from user_to money 
1  1  2  23  //User 1 gets $23 to 2 
2  1  3  -15  //User 1 owes $15 from 3 
3  2  3  10  //User 2 gets $10 from 3 

而作为新的交易都会通过计算添加到数据库中，我将更新这些表新的总数。所以我只保留每个用户最近的可用负债。 这样做的问题是，由于我没有为每笔交易保留余额（或快照），因此我将无法前往某个特定交易x并找出在该特定交易中欠谁/多少的人。我只能得到所有交易的总余额。

策略2： 待办事项策略1以及以下 保持交易总额/余额在另一个数据库表中对每一项交易（就像银行声明，说明你在每个月底和每一笔交易余额）。 我看到的问题是，如果旧的交易值发生变化，我必须更新所有交易的余额（总计），因为总额现在已更改为旧交易>

我试过了通过sourceforge上的一些开源会计软件项目源代码，但我也认为这可能是一个好主意，得到你们的意见。

谢谢。

Answer 1

如果你想要一个规范化的数据库，那么你不应该保持总计在任何地方。相反，您只需遍历交易表并汇总每个帐户的值。

为了简化操作，最好更改事务表的结构：删除'user_to'字段，以便每个物理事务由表中的两行表示。您的结构会像

trans // primary key 
user // foreign key to users table 
money 
curdate 
details // a varchar field which holds the details of each transaction 

翻译你的数据到新的结构将得到数据，如

1;1;23;20/09/2013;concert tickets 
2;2;-23;20/09/2013; concert tickets 
3;3;15;21/09/2013;whatever 
4;1;-15,21/09/2013;whatever 
5;2;10;22/09/2013; 
6;3;-10;22/09/2013; 

然后计算别人的平衡简直变成

select users.name, sum (transactions.money) 
from transactions inner join users on users.id = transactions.user 
group by users.name 

此表结构需要你使用sql事务来确保您总是向表中写入一对匹配的行。

在实际会计计划中，交易表分为两部分：头部（包含交易ID，日期，细节，货币等）和行（用户，金钱等）。这种结构使得人们可以在有多个账户可以贷记或借记的情况下创建交易（例如，如果公司向某个客户开具了某项东西的发票并且对该销售收取了税费，那么该客户将被扣除，并且销售和税收抵免）。

如果您拥有大量账户，大量交易和法定需要提供年终账户，那么您可以创建一个表，其中包含每年每个账户的余额;计算总数意味着从当年开始算起，并将今年的交易总额加到先前存储的总额中。但从你的问题来看，这似乎是矫枉过正。

如果要仅显示给定日期的交易但仍显示总计，则需要两个查询：一个计算总计达到给定日期，另一个显示给定日期的交易。期末余额将是期初余额和所有显示的交易的总和。

Answer 2

，将满足您的要求的基本模型草案将是这样的：
对于任何User（我喜欢的客户），我们将有一个或多个Account S，该帐户有一个名为Balance属性 ，将显示该帐户的重命名余额。
在模型中，记录是金融行为的一个单位，其中涉及两个或两个以上的交易方，任何交易方都有一个账户，通常交易方（账户）中的一个将被扣除，另一个将被记入贷方。

当交易发生时（经过验证和业务逻辑）：
记录将被插入到交易表中。
两个或多个记录将被插入到事务详细信息表中。
帐户表中的两个或更多记录将被更新（余额字段将被更新）。

谁欠了谁

在您的样本这可以简单地通过交易细节表中的金额字段负号存档。
在现实世界中，情况会更加复杂，并且需要额外的表格和业务逻辑，例如银行业实施透支和备用存款。