為什么交易和退款要拆開不同的表

這篇文章主要講解了“為什么交易和退款要拆開不同的表”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“為什么交易和退款要拆開不同的表”吧！

1.背景

那是一個風和日麗的下午，當然，風和日麗的下午應該配點其他的形容詞，實在是我才疏學淺，只能用這個詞充當了下開頭…… (此處省略小五千字)

趕緊進入正文!

因為之前一直做聚合支付，而在使用過程中，也是支付和退款表拆開的，一直這么用，并沒有覺得不妥。

比如一個交易表基本就是這樣的：

退款表也差不多就是這樣：

大概兩個表就是這樣子的吧!像一些其他字段就先省略了，平常用著也覺得沒什么。

但是恰好那次那個小哥哥就問了這個問題，支付和退款為什么要分開記錄?

當時也是確實是實力不允許，我只是說了就是這么用的，把正向流程和逆向流程拆開，分開實現邏輯，比較方便。

2.個人見解

這里說的不僅僅是交易和退款，同時泛指正向交易和逆向交易，比如充值和消費，借款和貸款，賬戶出賬入賬等等，下面僅說說個人見解，只做討論，如果小伙伴有更好的說法，希望可以留言指出，共同學習。

對賬需要

對賬戶而言，出款表和入款表最后兩方的金額是能對的上的，也就是說收支平衡。

當然這個記在一個表里也是完全可以的。畢竟對出入賬只是流水沒有狀態變化，比如出賬中，入賬中，等等，流水表完全可以記在一個里面，然后用字段進行標識是出賬還是入賬。

拆表需要

在網上看資料經常會說分庫分表，而像訂單這種(交易/退款)完全兩種業務，使用兩張表相對而言比較合適，畢竟交易的訂單相比退款訂單要多的多。

字段設計

交易和退款是完全不同的兩種業務，不像賬戶流水就是資金記錄。

交易除了訂單狀態還有一些交易信息比如商戶號、優惠金額、實付金額、交易渠道、商品 id 名稱、備注等各種信息。

退款則是根據原單進行退款，需要記錄原始訂單號、退款金額(部分退款)、退款信息等。

雖然交易和退款總體上都包含 訂單號、狀態、金額等，但是如果強行放在一個表，就會導致以下問題：

很多字段為空的情況，比如交易不需要原始訂單號，退款需要存儲原始訂單號。本來可以設置索引來提高查詢效率的字段也不太合適設置了。

狀態也不一定可以完全兼容，像交易狀態和退款狀態就很難互相兼容。

開發效率

交易和退款分開之后，兩個人負責不同的業務進行開發，包括業務邏輯和查詢展示。如果放在一起，就很多字段不能保證別人知道有還是沒有，是存儲還是不存儲，畢竟表里設置的都可以為空。這種情況下需要很多溝通，或者干脆一個人進行開發。

設計模式及原則

其他從設計模式及原則的角度上來說，可以說是職責單一，當然再高大上偏理論的我這就扯不出來了。

3.總結

Q&A

Q: 那前端要將兩種甚至多種在一個列表展示該如何處理?

A: 在很多 APP 中大家看到的多種訂單都是在一個列表里面展示出來的，比如：支付寶的賬單頁面。

當然，如果前端分 tab 頁，分開展示不同的業務，那對后端來說簡直不要太友好。不過實際往往不是這樣，這時候就需要將訂單統一存儲。

在訂單成功的時候存儲到一個公共存儲中，可以通過 MQ 等，將數據保送到另一張表/庫，或者 ES  中用來存儲。這樣訂單查詢還可以和業務邏輯的表/庫分開。也可以通過 binlog 進行處理，這里的方案只做參考。

感謝各位的閱讀，以上就是“為什么交易和退款要拆開不同的表”的內容了，經過本文的學習后，相信大家對為什么交易和退款要拆開不同的表這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！