為什麼建立新專欄

建立《一文秒懂》這個專欄與以往《Grace development》和我部落格的個人分享文章不同，我對《一文秒懂》這個專欄的定位是一個有態度，高標準的技術專欄，而《Grace development》我依舊會講一些我們日常中會碰到的一些技術問題及我個人的經驗分享。

前言

本篇是以以往我在思否釋出的三篇《電商系統設計之商品（上中下）》彙總的一篇結合我這些年經歷的升級版，在文字描述與流程圖上更規範，這裡也貼上以往的三篇文章連結。

• 電商系統設計之商品 (上) https://segmentfault.com/a/11...
• 電商系統設計之商品 (中) https://segmentfault.com/a/11...
• 電商系統設計之商品 (下) https://segmentfault.com/a/11...

商品的設計是電商系統中佔據重要地位，如何設計出高擴充套件，高效能的商品系統並非一件簡單的事情，我的設計是參考網際網路各大佬的設計後自行研究的，並非完全正確，但也不完全錯誤，現在我設計的這套電商系統已經在使用，如果在邏輯上遇到什麼問題，會及時修改我關於電商系統相關文章的設計思想部分。

基本思想

見上圖，我們先講解下系統規格與自定義規格、系統屬性與自定義屬性的關於及其他們存在的意義。

SPU

SPU(Standard Product Unit)標準化產品單元

什麼叫標準化產品單元？

拋棄標準化一詞來看，產品單元？就是以一個產品為一個單位。例如你是手記銷售商，你在廠家進貨的時候說我要iphonex 100部型號隨意規格隨意，進貨的時候沒考慮到記憶體或者螢幕尺寸，這個時候你就把iphonex這個商品當作一個單位。這就是產品單位。再談標準化，只是一些人或一個人制定的這麼一個標準，所以稱為標準化產品單元，不要拿百度百科上的解釋反駁我，我只是用更通俗易懂的方式解釋一下SPU。

例如iphonex的價格也不同的地方，分別為iphonex 64g 是8888,iphonex 256g是18888。這個時候我們不能建立2個spu去管理這2個商品。這個時候就需要用到spu的概念了。

SKU

SKU(Stock Keeping Unit)庫存量單元

什麼叫庫存量單位?

字面意思來看，庫存則是指的某個商品的某個規格還有多少件，這個時候就不能只針對商品了。上面的例子iphonex有2個不同規格的商品，這個時候無法計算其每個規格的庫存(建立2個商品可是不切實際，未來管理會很複雜，就例如安踏的跑鞋有十幾個尺碼，難道要建立十幾個商品嗎？),此時只能針對當前商品再建立子商品，我們叫它規格，例如iphonex有儲存和顏色2個規格

有木有發現還是有點問題？那具體的儲存大小與具體顏色該如何表達呢？這個時候需要建立規格的子商品，我們稱他為屬性

這個每個屬性的結合則就是一個新的商品，我們稱它為SKU，一個SPU對應著N個SKU

這樣就生成了N個商品

iphonex 64G白色
iphonex 32G黑色
iphonex 256G白色 等等...

系統規格/屬性

為什麼要設立系統規格屬性呢？

盜用一張淘寶的圖，以上都是根據分類品牌設定好的規格及屬性

主要是為了方便商家新增商品及其對商品的規格屬性進行統一的管理，當然一個電商系統在前期運營的情況下儘量減少系統屬性規格的使用（方便商家入住嘛）。

自定義屬性就不用說了，不讓商家新增自己的規格和尺碼什麼的怎麼能行？

SPU與SKU的關聯

SPU對應多個SKU,SPU實際就是主商品表，類似於iphonex這款手機，而SKU則是這個商品繫結的規格表，類似與iphonex 紅色款,iphonex 黑色款等。

而主表與規格表也關聯了其他表

商品專輯

在淘寶的邏輯中,商家可為商品新增視訊和圖片，可為每個sku新增圖片。我們稱為專輯。將一組圖片及視訊類似歌手作家出專輯一樣，繫結到商品表和sku表上

相關品牌

每個商品都歸屬與一個品牌，例如iphonex歸屬與蘋果公司,小米8歸屬與小米公司一樣。品牌無需關聯到sku內，道理很簡單，當前的sku是iphonex歸屬與蘋果公司，自然而然iphonex下面的規格都屬於蘋果了。

繫結類目

有時品牌不僅僅歸屬與一個類目，還是以iphonex舉例，他是一部手機又是蘋果產品但他又是一個音樂播放器。注意，這個時候不要將當前品牌繫結到三個類目上，如果你這樣做了，未來的可維護性會很低。應該每個類目中繫結相同的品牌名稱，你一定會問那這樣資料垃圾不就產生了嗎？我沒有具體資料給你展現這樣做的好處。

但從業務說起，現在我需要統計每個類目下商品的購買數去做使用者畫像，你時你要如何區分當前這個商品到底是哪個類目下呢？無法區分，因為你將品牌繫結到了3個類目下，不知使用者到底是通過哪個類目點選進去購買的。

再者很多品牌公司不僅僅是做一個商品，類似索尼做mp3也做電視，手機，遊戲機等。所以類目對應多個品牌，品牌應對應多個類目並非關聯多個類目

鏈路解析

商品系統與訂單系統是相鋪相成的，當買家購買商品後將經歷一個過程

商品系統->訂單系統->交易系統->訂單系統->物流系統->售後系統

完成上述流程則是完成了一筆交易,經常網上購物的童鞋都懂這個。今天我們講下從商品系統到交易系統和訂單系統的儲存過程及其設計上的應該注意的“坑”。

關聯問題

現在有這麼一個場景

小明在某寶買了一部愛瘋手機,顏色是紅色,儲存是32G，他選擇使用某寶支付.

小明選擇購買SKU=001的產品，正常情況下訂單表應該與此SKU編碼相關聯來維持資料一致性。像這樣

這種設計有個弊端，商品的名稱及價格都不是固定，如果商戶修改了商品的標題或者其他的屬性，那小明當時買的愛瘋手機是8000元，結果過了幾年降價了商戶修改了價格，結果小明的購買清單裡也變成了修改後的價格，所以說這種僅僅關聯的設計是不可取的(至少在電商系統中不可取)。

像上表中設計，有人會問了 “那關聯的意義何在呢？”

我的回答是 “保持資料關聯” ，雖然商戶有可能改變商品屬性，但應該儘可能的記錄使用者所有的動作。

多商戶電商

實際在電商系統設計上，個人感覺不應區分多商戶的電商與單使用者的電商(至少開發者不應區分他們)，但前期設計上就應把多商戶概念帶入到系統內。哪怕只有一個官方專賣店呢？！

涉及到多商戶就需要考慮使用者統一下單問題了。

• 訂單是由購物車下單，多個商品來自多個商戶
• 如果進行拆單、分單
• 如何進行下單通知等等多商戶的問題

關於多商戶的問題不是本章的重點，本次我先提出這幾個疑問,感興趣的同學可以提前思考下，後續文章會詳細講解

訂單是由購物車下單，多個商品來自多個商戶

如果下單是來自多個商戶的商品，那麼訂單的資料庫介面應該這樣設計

訂單表

訂單詳情表

無論購買多少商品並且商品歸屬於多少個商戶，我們都應把使用者一次性購買的商品歸屬與一個訂單，訂單下再關聯多個商品的詳情。在售後操作上，也方便買家退換單個商品。

後臺功能列表

這裡提供下功能名稱與URL為參考

後臺的設計和操作套路我會單獨拿一篇文章來介紹。這裡只做一個大概的table。

相關資料表

https://github.com/CrazyCodes...

致謝

謝謝你看到這裡，希望我的文章能夠幫助到你。有什麼問題可以在評論區留言，我看到會第一時間回覆。謝謝！