Shulou(Shulou.com)05/31 Report--

This article mainly explains "Why transactions and refunds should be separated from different tables". The explanation in the article is simple and clear and easy to learn and understand. let's go deep into the editor's train of thought. Let's study and learn why transactions and refunds should be taken apart.

1. Background

It was a sunny afternoon, of course, a sunny afternoon should be accompanied by some other adjectives, I am so ignorant that I can only use this word as the beginning. (five thousand words are omitted here)

Get into the text quickly!

Because the aggregate payment has been done before, and in the process of use, it is also the payment and refund table taken apart, has been used in this way, and does not feel inappropriate.

For example, a transaction table basically looks like this:

Field type meaning idbigint primary key idtrans_idvarchar transaction number trans_amountbigint order amount trans_statustinyint transaction status. Create_timedatetime creation time update_timedatetime update time

The refund form is something like this:

Field type meaning idbigint primary key idrefund_idvarchar refund order number origin_trans_idvarchar original transaction number refund_statustinyint refund status refund_amountbigint refund amount … Create_timedatetime creation time update_timedatetime update time

Maybe that's what the two watches look like! For example, some other fields are omitted first, and it doesn't matter when you use them.

But at that time, the little brother asked this question, why should the payment and refund be recorded separately?

At that time, it was also true that the strength was not allowed. I just said that it was used in this way. It is more convenient to separate the forward process from the reverse process and realize the logic separately.

two。 Personal opinion

What we are talking about here is not only transactions and refunds, but also forward transactions and reverse transactions, such as recharge and consumption, loans and loans, account entry, etc., below is just a personal opinion, only for discussion, if the partner has a better statement. I hope you can leave a message and learn together.

Reconciliation needs

As far as the account is concerned, the amounts of the last two parties of the payment table and the income form can be matched, that is to say, the balance of payments.

Of course, it is perfectly OK to record this in a table. After all, there is no change in the state of the incoming and outgoing accounts, such as out-of-account, entry, and so on, the flow meter can be recorded in one, and then use the field to identify whether it is out of the account or in the account.

It is necessary to open the meter.

Looking at the data online, it is often said that the sub-database sub-table, and such as the order (transaction / refund) completely two kinds of business, the use of two tables is relatively appropriate, after all, the transaction order is much more than the refund order.

Field design

Transactions and refunds are two completely different businesses, unlike account flows, which are capital records.

In addition to the order status, there are also some transaction information, such as merchant number, preferential amount, actual payment amount, transaction channel, commodity id name, remarks and so on.

A refund is based on the original order, which requires recording the original order number, refund amount (partial refund), refund information, etc.

Although transactions and refunds generally include order number, status, amount, etc., if forced on a table, it will lead to the following problems:

In many cases where the field is empty, for example, the original order number is not required for the transaction, and the original order number needs to be stored for the refund. Fields that could have been set up to improve query efficiency are no longer appropriate.

Status is not necessarily fully compatible, such as transaction status and refund status are difficult to be compatible with each other.

Development efficiency

After the transaction and the refund are separated, the two are responsible for the development of different businesses, including business logic and query presentation. If put together, many fields can not guarantee that others know whether there is or not, whether to store or not to store, after all, the table settings can be empty. In this case, you need a lot of communication, or simply develop on your own.

Design patterns and principles

Other from the design pattern and principle point of view, it can be said that the responsibility is single, of course, no matter how high-end and superior theory, I can not pull it out.

3. Summary

Quan A

Q: how should the front end show two or more of them in one list?

A: many of the orders you see in many APP are displayed in a single list, such as Alipay's billing page.

Of course, if the front end is divided into tab pages and different businesses are displayed separately, it is simply not too friendly for the back end. However, this is often not the case, so it is necessary to store the order uniformly.

When the order is successful, it can be stored in a public storage, and the data can be guaranteed to another table / library through MQ, etc., or used to store in ES. In this way, the order query can also be separated from the table / library of the business logic. It can also be handled through binlog, and the scheme here is for reference only.

Thank you for your reading, the above is the content of "Why transactions and refunds need to take apart different tables". After the study of this article, I believe you have a deeper understanding of why transactions and refunds should be taken apart. Specific use also needs to be verified by practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.