1
klesh 2016-05-07 23:39:03 +08:00 3
一般的电商系统会采用第 3 种,像淘宝、京东这些,是转化到余额再提现。这种方案要考虑 3 大问题:
1. 一致性,订单在结算时,必须同时完成订单的状态转化以及余额的变化,要么一起成功,要么一起失败,可通过事务解决。 2. 原子性,要考虑客户端并发提交结算请求,必须保证事务只执行一次。 3. 安全性,牵涉到钱的问题,那整个系统必须尽量安全,起码 sql 注入是必须要考虑并防止的,数据 库的保密工作要做好,不允许外部连接之类是必须的,备份要做好。 https 神马的必须要上,金额巨大必须要有第三方校验。 至少追踪,那日志系统是必须的,每次余额的变化都要写日志, 把当前余额,变动量,什么原因,相关订单号纪录起来以便追溯。 不过你们是月结,其实方案 2 也挺不错的,复杂性会低很多,也不用去冻结什么的,你反正给他一个搜索指定时间段内的数据,然后统计给结果,至于实际上财务怎么去结算由他们自己去纪录,这样风险反而更小。方案 1 是最不现实的,只要有人用的东西就不可能存在绝对不犯错的情况,不允许修改,错了怎么办? 无论采用什么方案, cpu 及数据库负载不会太大的,我算你每天一万单,一个月也不过区区三十万条纪录, sql 操作很快的,若是分单结算,瞬间负载不值一提。 无论采用哪种方案,人工校验都是必须的!隔一段时间对一下帐很有必要,特别是初期实施的时候,即使你写的逻辑滴水不露,服务器上面也不可能百分百安全。 总而言之,事世无绝对,你要考虑到第一个相关的部分都可能出问题,可能被攻破,可能会崩溃。 |
2
yeyeye OP @klesh
关于你说的一致性 事务我也是想到了的 到时候肯定用它! 关于你说的原子性 我接入过 QQ 互联接口 知道用随机字符来防止重复提交 ! 关于你说的安全性 我也充分觉得必须上 https 尽可能的保障安全(多地要使用这个系统) SQL 部分全部绑定数据(没有这方面的经验,但是为了防止 SQL 注入的问题 这头也是必须的),没有上传模块,所以搞定 SQL 注入和 XSS 以及 HTTPS 就基本上 OK 啦 我甚至考虑了前端只暴露出一个验证用户密码的接口 后端目录名随机生成个 至于服务器安全…… 说真的 我倒是最担心操作人员的账号安全问题 所以我认为锁数据是有必要的 当然锁之前肯定是要每天人工检查检查 想象很完美 或许要办到太难了 但是我这边有一个特性 就是单据是要传给另一人逐个操作的(每一小单都是要联系客户的 照着单据来联系 有错可以调整回来 除非忘记了……) 由于人力不充足 如果在钱上出毛病亏的也是自家的(家人创业) 所以好犹豫 哈哈 好啦 感谢你的耐心解答以及补充 帮助很大! |
3
Mac 2016-05-08 04:36:13 +08:00 1
这取决于你的数据量,小企业的财务数据,随便你用 1 、 2 、 3 都完全没有问题。你完全不用考虑性能问题,该考虑的是前端怎样让财务的操作更简便,比如对账和销帐。
|
4
dxwwym 2016-05-08 08:22:29 +08:00 via iPhone 1
作为一名对会计有一些了解的人的给几点建议
1.一般企业财务系统记账原则要按权责发生制而不是收付实现制,应收、应付、预收、预付账款的概念。 2.不论出于什么原因要删除某笔记账数据都算抹账或者叫红蓝字冲正,而不是简单的从数据库删除该笔数据,原则上要对原有数据进行保留冲正该笔后再记正确的。 3.考虑数据正确性校验可以参考银行的做法每日批量,也可以每 10 日进行批量校验,最起码月底要试算平衡。 4.如果是单独的进销存...可以设计的宽松一些 |
5
billlee 2016-05-08 14:11:21 +08:00 1
就缺一个产品经理了
|