【发布时间】:2016-06-16 13:51:44
【问题描述】:
这感觉就像是 stackoverflow 社区中的重复帖子。但我真的很想验证我计划在会计应用程序中实施的交易(贷记/借记)的想法
我搜索了社区,发现了几个与该主题相关的线程。但这些线程中没有一个 cmets 解释了“如果实施这种方法会发生什么。”
所以我期待社区提出反对我的想法的想法。 还有建议,以便我改进我的设计。
这是我的应用领域:
我发现我的客户(一家审计公司)每年最多处理 (一个粗略的整数)720 万 笔交易。它包括来自不同公司的若干审计数据。
因此,当数据量达到更高数量时,处理如此大量的数据可能会影响应用程序的性能。
我在数据库中存储交易数据的方法是这样的:
将交易和帐户存储为单独的实体。
帐户 >:accid(PK)|登录名 |期初余额 |当前金额 | comp_id(FK)
交易 >: trid(pk) |三标识符(UUID) |金额 | tr_state
存在多对多关系。
我将贷记和借记视为单独的角色,每个交易和账户都有许多贷记和借记角色。
账户 1:M 信用 M:1 交易
账户 1:M 借记 M:1 交易
当我要注册交易时:
在交易表中注册交易
考虑贷方方式插入贷方并反映借方方式以确保总金额余额。
平衡会在业务逻辑层实现
当我想检索特定帐户的数据时:
accid > 通过 Credit Union 搜索 accid 通过借方搜索
请考虑我是此帐户申请域的新手。所以帮我设计一下吧。
【问题讨论】:
标签: database-design transactions entity-relationship audit accounts