请教【财务记账类系统】逻辑处理及数据库设计优选方案

类似银行记账，数据库设计
方案1：一个流水账表，查询余额时，统计该用户所有历史记录，得出余额，返给客户端；
缺点：查询余额时对数据库查询量大，尤其时间跨度大，同一用户记录数多的情况下。
优点：保证数据的正确性。

方案2：一个流水表，一个余额表，程序处理时将余额表与流水表同步。
缺点：存在余额表未能与流水表同步一致的可能性，导致余额数据不准确；优点：提高数据查询性能。

方案3：流水表中增设一个余额字段，每次插入记录时，用上次余额与本次存取做加减后计入。
这个方案尚未细思。

问题：1、在实际业务中哪种方案更合理？
2、对方案2来说，编程时更新余额表语句与插入流水语句哪个在前？
例如，张三现有存款1000元，本次取款100元，本条取款记录转交第三方进行异步处理，如果插入流水后再在余额表中更新余额，那么或许会因为数据库服务器、网络故障等因素导致流水语句执行成功，而更新余额表语句未执行，此时张三已取款，但余额数据仍是1000。这对平台来说是安全漏洞。
反之，如果是存款，更新余额在前，流水在后，余额加了，但流水未执行，存款行为也未执行，这对平台来说也是不利的，安全漏洞。
当然，可以通过逻辑优化防范这个漏洞，我现在的问题是：在实际业务中，大家常用的经过实践检验的最佳流程是怎样的？
3、方案2的情况下，张三取款100，余额表中是更新张三余额1000为900，还是插入一条新记录，张三余额900，查询时取最新记录，这有点类似方案3.
4、张三转给李四100元，这在流水中应计入1条记录还是2条记录？
我认为是应计入两条记录：（1）张三转出100，（2）李四转入100。
为使这两条记录关联，方便查账，设计一个账单号，两条记录计入同一个账单号？
形如
流水号        用户    交易类型    交易对象  交易金额     单号
180011       张三       付款         李四          -100        abc123
180056       李四       收款         张三          100         abc123
这里，单号使用流水号合适吗？形如：
流水号    用户    交易类型    交易对象  交易金额     单号
180011    张三       付款         李四          -100       180011
180056    李四       收款         张三          100        180011

你这是打算做一个计算机专业的课程设计，还是真的是用于生产环境的财务系统？

引用：JackJiang 发表于 2018-10-12 10:24
你这是打算做一个计算机专业的课程设计，还是真的是用于生产环境的财务系统？

生产环境财务系统

引用：freeman 发表于 2018-10-12 10:25
生产环境财务系统

也没有一个有经验的或者已有的系统可参考，就这么凭感觉来干？

引用：JackJiang 发表于 2018-10-12 10:27
也没有一个有经验的或者已有的系统可参考，就这么凭感觉来干？

哈哈，赤膊上阵，不过倒不是凭感觉，是认真分析，反复求证推敲的。还望jack在框架上指点一二

引用：JackJiang 发表于 2018-10-12 10:27
也没有一个有经验的或者已有的系统可参考，就这么凭感觉来干？

这不是正在征求经验参考么。这两天在看楚汉传奇，刘邦打天下也完全没经验，摸着石头过河也得了天下不是么

引用：freeman 发表于 2018-10-12 10:31
哈哈，赤膊上阵，不过倒不是凭感觉，是认真分析，反复求证推敲的。还望jack在框架上指点一二

你的方案里：
方案一数据是最准确的，但随时时间的推移性能会越来越差；
方案三是很容易发生数据不一致的，不要以为上次余额计算准确了，这次做加减的结果也会是正确的。实际生产环境下，什么意外都有可能发生，不一致的可能性远比你想的大（因为我很多年以前是做erp的，这个是深有体会）。

方案二看起来好像是容易产生数据同步问题，但你深挖一下，什么时候需要同步，数据的实时性有多少要求，这个方案可能是个折中方案。不信你试着分析分析，跟钱有关的数据和算法，一定是要以准确为前提，其它在此前提无法保证的情况下都要退居2线再考虑，否则没有哪个财务愿用用这个系统。在财务眼里是1分钱都不能出错的，出错账就平不了，这也是为什么金蝶和用友做的东西，一般公司都不敢碰的原因

建议用成熟的财务软件来解决吧，自已设计很麻烦的，钱的计算舍入什么的都很繁琐，写财务这类的代码小心翼翼，不允许出一点差错的~~

引用：JackJiang 发表于 2018-10-12 10:44
你的方案里：
方案一数据是最准确的，但随时时间的推移性能会越来越差；
方案三是很容易发生数据不一致 ...

好的，目前我也正按方案2设计，因为没经验心里没底，你这么说我就心里亮快些了。
对于第2个问题，我目前是按照利于平台的取舍设计的，也就是，万一不一致，先保证平台不会亏，然后根据用户的报错再核对人工处理。其实用户也不会亏，记录没更新的情况下是不会执行存取款行为的，只是流水记录没有及时正确更新。

引用：大马仕格 发表于 2018-10-12 10:45
建议用成熟的财务软件来解决吧，自已设计很麻烦的，钱的计算舍入什么的都很繁琐，写财务这类的代码小心翼翼 ...

是的，这几天大部分时间在发呆推敲逻辑，程序代码进展几乎停了，为一个环节处理可能反复推敲两天

方案二，可以在缓存中同步保存一份，以调高查询效率

引用：dengpeng1994 发表于 2018-10-12 11:06
方案二，可以在缓存中同步保存一份，以调高查询效率

是的，用redis这样的缓存存储预计算的结果是个很好的主意。
而且缓存里可记住本次缓存的计算时间，读取数据时如果怕这个数据不是最新的，可以再做第2个动作：就是及时统计一下这个时间之后的交易（用当前缓存里的余额结果再跟本次及时统计的时间段数据进行合并计算）。这样的话既能保证数据的准确性，也能保证性能，因为缓存的计算时间至今肯定是个很短的时间，第2个实时统计的动作里，涉及的最新交易明细肯定很少，这个实时查询性能也就不是问题了。

引用：dengpeng1994 发表于 2018-10-12 11:06
方案二，可以在缓存中同步保存一份，以调高查询效率

可以先找一套开源的财务系统学习一下，这里面的数据类型设计，舍入计算，都很有讲究，不然弯路总是要走的....

引用：IMDeveloper 发表于 2018-10-12 15:58
可以先找一套开源的财务系统学习一下，这里面的数据类型设计，舍入计算，都很有讲究，不然弯路总是要走的.. ...