是不是只有执行多次数据库操作啊？ - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

写一个交易系统，记录客户付钱，并且从帐户上扣钱，系统要记录交易的内容，和帐户的变化状况，系统要做这几件事
1.扣钱
2.记交易日志
3.帐户日志
三张表：帐户表 交易日志表 帐户日志表
写一个方法：
一个事务里面要做这几样事：
beginwork()
update(帐户表）
insert(交易日志表)
insert(帐户日志表)
总觉得一个方法里面多次执行sql性能会不会不太好，不知道各位大大们有没有做过相似的系统，是不是要多张表来做这种交易数据的处理?
这些记录都有金额这个字段，万一要对这笔交易，进行修改的话，那启不是要把三条记录的字段都改掉，并且二张表都要有外键，去关联主表的ID，这样修改才知道是修改这三个表中的相应记录，是吗？
我的意思是：三个表结构中都有“金额”这个字段，如果修改这笔交易，那么程序要找到三张表对应的三条记录，然后进行修改
这样的表设计有点不是3NF的，本来，“金额”字段放在一个表就行了，三个表反正有外键关联的，改金额只要改一个就行了，比如放在交易表中，而查询其他表的时候，如果也要金额，那么就join 交易表就行了
但是如果现在的银行系统，你要修改交易，
如果是抹帐，借贷方向不变就反向记录一条记录就够了，金额为负滴。
要不就是借贷方向相反做一个交易，根本不需要去修改啊。
交易日志的记录怎么能够去修改呢？日志是用来保存原始记录的，是实际发生事件的忠实记录。就算要因为发生错误，也需要重新记录新的日志。
如果谁都可以去调整原始交易历史记录，这不是危险性很高？
平台本身有一个帐户表
平台产生交易请求到银行会计系统，交易信息（收方帐号，付方帐号，金额）等，会计系统是会记录的，但是平台本身是不是也要记录的，中间业务系统要统计交易信息的时候，总不能向会计系统发请求吧，这样启不是很慢，也没办法分页
这样的话，如果要做反交易的话，是不是只能限制在中间业务平台那块做，如果会计系统中做冲正的的话，中间业务平台相应的记录是不会变的，这样两边查询的数据（中间平台交易统计）就会不一样了
中间平台内部呢，有不同的业务种类，业务种类的属性用一个通用的表不能表达出来，所以就用了几个种类表。
然后一个总表，总表是和会计系统中的表结构相似，只有（收方帐号，付方帐号，金额）等通用信息
几个子表呢，比如手机费表，煤气费表什么的，如果发生了一笔手机费，会同时在两张表中记录，一个是总表，一个是手机费表，这样设计是不是很不合理？当我要修正一笔手机费用的时候，就要改两张表。
如果用一个大表（里面用费用类别来区分手机费，煤气费什么的）那这个表字段会很多，并且对一种业务来说，很多字段没用，总之是很困扰。。。
[B]平台本身有一个帐户表
平台产生交易请求到银行会计系统，交易信息（收方帐号，付方帐号，金额）等，会计系统是会记录的，但是平台本身是不是也要记录的，中间业务系统要统计交易信息的时候，总不能向会计系统发请求吧，这样启不是很慢，也没办法分页
平台本身应该记录。会计系统是帐务信息，中间业务平台统计是中间业务交易信息。理论上查询交易不需要去向会计系统发请求。[/COLOR] 。
这样的话，如果要做反交易的话，是不是只能限制在中间业务平台那块做，如果会计系统中做冲正的的话，中间业务平台相应的记录是不会变的，这样两边查询的数据（中间平台交易统计）就会不一样了
对的。交易冲正应该从发生错误的原始交易源开始冲。不能在会计系统中一边冲。比如你用借记卡缴费，难道只从一边的公司代收代付帐户的帐务嘛？[/COLOR]
中间平台内部呢，有不同的业务种类，业务种类的属性用一个通用的表不能表达出来，所以就用了几个种类表。
然后一个总表，总表是和会计系统中的表结构相似，只有（收方帐号，付方帐号，金额）等通用信息
几个子表呢，比如手机费表，煤气费表什么的，如果发生了一笔手机费，会同时在两张表中记录，一个是总表，一个是手机费表，这样设计是不是很不合理？当我要修正一笔手机费用的时候，就要改两张表。
如果用一个大表（里面用费用类别来区分手机费，煤气费什么的）那这个表字段会很多，并且对一种业务来说，很多字段没用，总之是很困扰。。。 [/B]
表设计应该是分业务设计，也没有问题[/COLOR]