前言
近期做新我的项目,在设计表构造的时候,忽然想起来之前面试的时候遇到的一个问题,那时候也是老成持重,对很多货色只知其一; 不知其二(当然当初也是),过后那个小哥哥问我为什么交易和退款要拆成两个表?是基于什么思考?有什么益处和长处么?
公众号:『刘志航』,记录工作学习中的技术、开发及源码笔记;时不时分享一些生存中的见闻感悟。欢送大佬来领导!
背景
那是一个风和日丽的下午,当然,风和日丽的下午应该配点其余的形容词,切实是我满腹经纶,只能用这个词充当了下结尾……(此处省略小五千字)
连忙进入注释!
因为之前始终做 聚合领取,而在应用过程中,也是领取和退款表拆开的,始终这么用,并没有感觉不妥。
比方一个交易表根本就是这样的:
字段 | 类型 | 含意 |
---|---|---|
id | bigint | 主键 id |
trans_id | varchar | 交易订单号 |
trans_amount | bigint | 订单金额 |
trans_status | tinyint | 交易状态 |
…… | …… | …… |
create_time | datetime | 创立工夫 |
update_time | datetime | 更新工夫 |
退款表也差不多就是这样:
字段 | 类型 | 含意 |
---|---|---|
id | bigint | 主键 id |
refund_id | varchar | 退款订单号 |
origin_trans_id | varchar | 原始交易订单号 |
refund_status | tinyint | 退款状态 |
refund_amount | bigint | 退款金额 |
…… | …… | …… |
create_time | datetime | 创立工夫 |
update_time | datetime | 更新工夫 |
大略两个表就是这样子的吧!像一些其余字段就先省略了,平时用着也感觉没什么。
然而恰好那次那个小哥哥就问了这个问题,领取和退款为什么要离开记录?
过后也是的确是实力不容许,我只是说了就是这么用的,把正向流程和逆向流程拆开,离开实现逻辑,比拟不便。
个人见解
这里说的不仅仅是交易和退款,同时泛指正向交易和逆向交易,比方充值和生产,借款和贷款,账户出账入账等等,上面仅说说个人见解,只做探讨,如果小伙伴有更好的说法,心愿能够留言指出,独特学习。
对账须要
对账户而言,出款表和入款表最初两方的金额是能对的上的,也就是说 收支平衡。
当然这个记在一个表里也是齐全能够的。毕竟对出入账只是流水没有状态变动,比方出账中,入账中,等等,流水表齐全能够记在一个外面,而后用字段进行标识是出账还是入账。
拆表须要
在网上看材料常常会说 分库分表 ,而像订单这种(交易 / 退款)齐全两种业务,应用两张表相对而言比拟适合,毕竟 交易 的订单相比退款订单要多的多。
字段设计
交易和退款是齐全不同的两种业务,不像账户流水就是资金记录。
交易除了订单状态还有一些交易信息比方商户号、优惠金额、实付金额、交易渠道、商品 id 名称、备注等各种信息。
退款则是依据原单进行退款,须要记录原始订单号、退款金额(局部退款)、退款信息等。
尽管交易和退款总体上都蕴含 订单号、状态、金额等,然而如果强行放在一个表,就会导致以下问题:
- 很多字段为空的状况,比方交易不须要原始订单号,退款须要存储原始订单号。原本能够设置索引来进步查问效率的字段也不太适合设置了。
- 状态也不肯定能够齐全兼容,像交易状态和退款状态就很难相互兼容。
开发效率
交易和退款离开之后,两个人负责不同的业务进行开发,包含业务逻辑和查问展现。如果放在一起,就很多字段不能保障他人晓得有还是没有,是存储还是不存储,毕竟表里设置的都能够为空。这种状况下须要很多沟通,或者罗唆一个人进行开发。
设计模式及准则
其余从设计模式及准则的角度上来说,能够说是职责繁多,当然再高大上偏实践的我这就扯不进去了。
总结
Q&A
Q: 那前端要将两种甚至多种在一个列表展现该如何解决?
A: 在很多 APP 中大家看到的多种订单都是在一个列表外面展现进去的,比方:支付宝的账单页面。
当然,如果前端分 tab 页,离开展现不同的业务,那对后端来说几乎不要太敌对。不过理论往往不是这样,这时候就须要将订单对立存储。
在订单胜利的时候存储到一个公共存储中,能够通过 MQ 等,将数据输送到另一张表 / 库,或者 ES 中用来存储。这样订单查问还能够和业务逻辑的表 / 库离开。也能够通过 binlog 进行解决,这里的计划只做参考。
结束语
之所以写这篇文章,也是为了总结一下最近工作中遇到的问题,以及解决办法。同时一瞬间想起来了很久前遇到的雷同的问题。
如果小伙伴们还有别的认识,欢送留言,发表本人的意见及认识,独特探讨。