前言《最近在做一个新的项目，在设计表结构的时候，突然想起了之前面试遇到的一个问题，那时候还是个初出茅庐的人，很多东西都不是很懂（当然我现在还是这么做的）当时小哥问为什么要把交易和退款拆分成两张表？有什么考虑？有什么好处和好处吗？”1.背景那是一个阳光明媚的下午。当然，sunnyafternoon应该跟其他的形容词，我实在是孤陋寡闻，所以只能用这个词作为下句的开头……（这里省略小五千字）赶紧进文本！因为我之前一直在做聚合支付，在使用的过程中，也是支付和退款。手表拆了，一直这样用，我觉得没有错。例如，一个交易表基本上是这样的：fieldtypemeaningidbigintprimarykeyidtrans_idvarchartransactionordernumbertrans_amountbigintorderamounttrans_statustinyinttransactionstatus...create_timedatetimecreatetimeupdate_timedatetimeupdatetime退款表大概是这样的：字段类型含义idbigint主键idrefund_idvarchar退款订单号origin_trans_idvarchar原始交易订单号refund_statustinyint退款状态refund_amountbigint退款金额………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………。那次小哥就问了这个问题，为什么要把付款和退款分开记？当时确实实力不允许，我只是说了这么用，把正向过程和反向过程分开，把逻辑分开实现，比较方便。2.个人意见。这里所说的不仅仅是交易和退款，泛指正向交易和反向交易，比如充值和消费，借贷，提现和存款等。以下仅代表个人观点，仅供讨论，如果大家有更好的说法，希望大家留言指出，共同学习。对账，就账户而言，提款表和存款表中最后两方的金额是可以匹配的，也就是收支平衡。当然，完全可以将其记录在表格中。毕竟进出账只是没有状态变化的流，比如正在发账，正在入账等，流表可以记录在一张，然后用字段来标识不管是账号还是账号。拆表需要看网上的资料。常说数据库分表，有订单（交易/退款）等两类业务。用两张表相对比较合适。毕竟，交易订单是相对于退款订单而言的。多得多。现场设计交易和退款是两个完全不同的业务，不像账户流转，是资金的记录。交易除了订单状态，还有一些交易信息，如商户号、折扣金额、实际支付金额、交易渠道、商品id名称、备注等信息。退款以原订单为准，需要记录原订单号、退款金额（部分退款）、退款信息等。虽然交易和退款一般都包含订单号、状态、金额等，但是如果强行放在一个表中，会造成以下问题：很多字段为空，比如交易不需要原始订单号，以及退款需要保存原始订单号。本来可以建立索引提高查询效率的字段不适合设置。状态不一定完全兼容，比如交易状态和退款状态很难兼容。开发效率交易和退款分离后，两个人分别负责不同业务的开发，包括业务逻辑和查询展示。如果放在一起，很多字段并不能保证别人知道它们存在与否，存储还是不存储，毕竟表中的设置可以为空。在这种情况下，需要大量的沟通，或者干脆一个人开发。设计模式和原则。从设计模式和原则上来说，可以说是职责单一。3.总结问答：前端应该如何在一个列表中显示两个甚至多个订单？A：在很多APP中，你看到的各种订单都是在一个列表中显示的，比如：支付宝账单页面。当然，如果前端分成tab页分别展示不同的业务，对后端就不太友好了。然而，实际情况往往并非如此。这时候就需要对订单进行统一存储。下单成功后存储到一个公共存储中，可以通过MQ等将数据转移到另外一个表/库中，或者用于ES中的存储。这样订单查询也可以和业务逻辑表/库分离。也可以通过binlog来处理，这里的解决方案仅供参考。结语之所以写这篇文章，是想总结一下最近工作中遇到的问题，以及如何处理。与此同时，我突然想起了很久以前遇到的同样问题。本文转载自微信公众号“刘志航”，可通过以下二维码关注。转载本文请联系刘志航公众号。
