這篇文章主要講解了“為什么交易和退款要拆開不同的表”,文中的講解內容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“為什么交易和退款要拆開不同的表”吧!
成都一家集口碑和實力的網站建設服務商,擁有專業(yè)的企業(yè)建站團隊和靠譜的建站技術,10多年企業(yè)及個人網站建設經驗 ,為成都上1000+客戶提供網頁設計制作,網站開發(fā),企業(yè)網站制作建設等服務,包括成都營銷型網站建設,成都品牌網站建設,同時也為不同行業(yè)的客戶提供成都網站制作、成都網站設計、外貿營銷網站建設的服務,包括成都電商型網站制作建設,裝修行業(yè)網站制作建設,傳統(tǒng)機械行業(yè)網站建設,傳統(tǒng)農業(yè)行業(yè)網站制作建設。在成都做網站,選網站制作建設服務商就選成都創(chuàng)新互聯(lián)公司。
1.背景
那是一個風和日麗的下午,當然,風和日麗的下午應該配點其他的形容詞,實在是我才疏學淺,只能用這個詞充當了下開頭…… (此處省略小五千字)
趕緊進入正文!
因為之前一直做聚合支付,而在使用過程中,也是支付和退款表拆開的,一直這么用,并沒有覺得不妥。
比如一個交易表基本就是這樣的:
字段 | 類型 | 含義 |
---|---|---|
id | bigint | 主鍵 id |
trans_id | varchar | 交易訂單號 |
trans_amount | bigint | 訂單金額 |
trans_status | tinyint | 交易狀態(tài) |
…… | …… | …… |
create_time | datetime | 創(chuàng)建時間 |
update_time | datetime | 更新時間 |
退款表也差不多就是這樣:
字段 | 類型 | 含義 |
---|---|---|
id | bigint | 主鍵 id |
refund_id | varchar | 退款訂單號 |
origin_trans_id | varchar | 原始交易訂單號 |
refund_status | tinyint | 退款狀態(tài) |
refund_amount | bigint | 退款金額 |
…… | …… | …… |
create_time | datetime | 創(chuàng)建時間 |
update_time | datetime | 更新時間 |
大概兩個表就是這樣子的吧!像一些其他字段就先省略了,平常用著也覺得沒什么。
但是恰好那次那個小哥哥就問了這個問題,支付和退款為什么要分開記錄?
當時也是確實是實力不允許,我只是說了就是這么用的,把正向流程和逆向流程拆開,分開實現(xiàn)邏輯,比較方便。
2.個人見解
這里說的不僅僅是交易和退款,同時泛指正向交易和逆向交易,比如充值和消費,借款和貸款,賬戶出賬入賬等等,下面僅說說個人見解,只做討論,如果小伙伴有更好的說法,希望可以留言指出,共同學習。
對賬需要
對賬戶而言,出款表和入款表最后兩方的金額是能對的上的,也就是說收支平衡。
當然這個記在一個表里也是完全可以的。畢竟對出入賬只是流水沒有狀態(tài)變化,比如出賬中,入賬中,等等,流水表完全可以記在一個里面,然后用字段進行標識是出賬還是入賬。
拆表需要
在網上看資料經常會說分庫分表,而像訂單這種(交易/退款)完全兩種業(yè)務,使用兩張表相對而言比較合適,畢竟交易的訂單相比退款訂單要多的多。
字段設計
交易和退款是完全不同的兩種業(yè)務,不像賬戶流水就是資金記錄。
交易除了訂單狀態(tài)還有一些交易信息比如商戶號、優(yōu)惠金額、實付金額、交易渠道、商品 id 名稱、備注等各種信息。
退款則是根據原單進行退款,需要記錄原始訂單號、退款金額(部分退款)、退款信息等。
雖然交易和退款總體上都包含 訂單號、狀態(tài)、金額等,但是如果強行放在一個表,就會導致以下問題:
很多字段為空的情況,比如交易不需要原始訂單號,退款需要存儲原始訂單號。本來可以設置索引來提高查詢效率的字段也不太合適設置了。
狀態(tài)也不一定可以完全兼容,像交易狀態(tài)和退款狀態(tài)就很難互相兼容。
開發(fā)效率
交易和退款分開之后,兩個人負責不同的業(yè)務進行開發(fā),包括業(yè)務邏輯和查詢展示。如果放在一起,就很多字段不能保證別人知道有還是沒有,是存儲還是不存儲,畢竟表里設置的都可以為空。這種情況下需要很多溝通,或者干脆一個人進行開發(fā)。
設計模式及原則
其他從設計模式及原則的角度上來說,可以說是職責單一,當然再高大上偏理論的我這就扯不出來了。
3.總結
Q&A
Q: 那前端要將兩種甚至多種在一個列表展示該如何處理?
A: 在很多 APP 中大家看到的多種訂單都是在一個列表里面展示出來的,比如:支付寶的賬單頁面。
當然,如果前端分 tab 頁,分開展示不同的業(yè)務,那對后端來說簡直不要太友好。不過實際往往不是這樣,這時候就需要將訂單統(tǒng)一存儲。
在訂單成功的時候存儲到一個公共存儲中,可以通過 MQ 等,將數(shù)據保送到另一張表/庫,或者 ES 中用來存儲。這樣訂單查詢還可以和業(yè)務邏輯的表/庫分開。也可以通過 binlog 進行處理,這里的方案只做參考。
感謝各位的閱讀,以上就是“為什么交易和退款要拆開不同的表”的內容了,經過本文的學習后,相信大家對為什么交易和退款要拆開不同的表這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián),小編將為大家推送更多相關知識點的文章,歡迎關注!
分享名稱:為什么交易和退款要拆開不同的表
標題網址:http://bm7419.com/article26/psdhcg.html
成都網站建設公司_創(chuàng)新互聯(lián),為您提供微信公眾號、自適應網站、企業(yè)建站、網頁設計公司、云服務器、電子商務
聲明:本網站發(fā)布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯(lián)