当前位置:网站首页>Have you ever thought about why the transaction and refund have to be split into different tables

Have you ever thought about why the transaction and refund have to be split into different tables

2020-11-08 23:46:00 Liu Zhihang

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 :

  1. 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 .
  2. 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 .

LDZJYc-IFUqcP

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 .

版权声明
本文为[Liu Zhihang]所创,转载请带上原文链接,感谢