Preface
Do new projects recently , When designing table structure , Suddenly I remembered a question I met in the interview before , At that time, I was just a beginner , A little knowledge of a lot of things （ Now, of course ）, At that time, the little brother asked me why the transaction and refund had to be split into two tables ？ Based on what considerations ？ What are the benefits and advantages ？
official account ：『 Liu Zhihang 』, Record the skills in work study 、 Development and source notes ; From time to time to share some of the life experience . You are welcome to guide ！
background
It was a sunny afternoon , Of course , A sunny afternoon should be accompanied by other adjectives , It's just that I'm not very good at learning , This word can only be used as the beginning of the next …… （ The small five thousand words are omitted here ）
Get into the text ！
Because I've been doing it before Aggregate payment , And in the process of use , It's also a separate payment and refund form , Use it all the time , I don't think it's wrong .
For example, a trading table is basically like this ：
| Field | type | meaning |
|---|---|---|
| id | bigint | Primary key id |
| trans_id | varchar | Transaction order number |
| trans_amount | bigint | Order amount |
| trans_status | tinyint | Transaction status |
| …… | …… | …… |
| create_time | datetime | Creation time |
| update_time | datetime | Update time |
The refund form is almost like this ：
| Field | type | meaning |
|---|---|---|
| id | bigint | Primary key id |
| refund_id | varchar | Refund order number |
| origin_trans_id | varchar | Original transaction order number |
| refund_status | tinyint | Refund status |
| refund_amount | bigint | Refund amount |
| …… | …… | …… |
| create_time | datetime | Creation time |
| update_time | datetime | Update time |
Maybe that's how the two watches are ！ For example, some other fields are omitted first , I don't think it's very important to use it .
But just that time the little brother asked this question , Why should payment and refund be recorded separately ？
At that time, strength did not allow , I just said that's how it works , Separate the forward flow from the reverse flow , Separate implementation logic , It's more convenient .
Personal opinion
It's not just about deals and refunds , At the same time, it generally refers to forward trading and reverse trading , Such as recharge and consumption , Borrowing and lending , Account out of the account into the account and so on , Here's just my personal opinion , Just a discussion , If the partner has a better idea , I hope you can leave a message indicating , Learning together .
Reconciliation requires
For accounts , The amount of the last two parties in the payment statement and the income statement can be correct , in other words Balance of payments .
Of course, it can be written in a table . After all, it's just a running account with no status change , For example, in the account , In the account , wait , The running chart can be recorded in one , Then use the field to identify whether it is an account or an account .
It takes
Reading materials on the Internet often says Sub database and sub table , And like orders （ transaction / refund ） Two kinds of business , It is relatively appropriate to use two tables , After all transaction There are a lot more orders than refund orders .
Field design
Transaction and refund are two completely different businesses , Unlike an account flow, it's a record of funds .
In addition to the order status, there are also some transaction information, such as merchant number 、 Preferential amount 、 Amount paid 、 Trading channels 、 goods id name 、 Notes and other information .
The refund is based on the original order , The original order number needs to be recorded 、 Refund amount （ Partial refund ）、 Refund information, etc .
Although transactions and refunds generally include The order number 、 state 、 Amount, etc. , But if you force it into a table , It will lead to the following problems ：
- Many fields are empty , For example, the transaction does not need the original order number , The original order number needs to be stored for refund . It is not appropriate to set the index to improve the query efficiency .
- States may not be fully compatible , Transaction status and refund status are difficult to be compatible with each other .
Development efficiency
After the transaction is separated from the refund , Two people are responsible for different business development , Including business logic and query presentation . If put together , Many fields can't guarantee that others will know whether there is or not , Is it to store or not to store , After all, all the settings in the table can be empty . It takes a lot of communication in this case , Or develop it on your own .
Design patterns and principles
Others from the perspective of design patterns and principles , It can be said that the responsibility is single , Of course, I can't pull it out even if I'm a big up leaning theory .
summary
Q&A
Q: The front end will show how to handle two or more in a list ？
A: In many APP The various orders you can see are displayed in a list , such as ： Alipay's bill page .
Of course , If the front end is divided tab page , Show different businesses separately , That's hardly too friendly for the back end . But it's not always the case , At this time, we need to store the order in a unified way .
Store in a public store when the order is successful , Can pass MQ etc. , Take the data to another table / library , perhaps ES Used to store . In this way, the order query can also be combined with the business logic table / Library separation . It can also be done through binlog To deal with , The plan here is for reference only .
Conclusion
The reason why I wrote this article , It is also to summarize the problems encountered in recent work , And how to deal with it . At the same time, I remember the same problem I met a long time ago .
If the partners have other opinions , Welcome to leave a message , Express your opinions and opinions , Discuss together .
