最近事情有點多，所以系列文章已停止好多天了。今天我們繼續Springboot電商項目實戰系列文章。到目前為止，整個項目的架構和基礎服務已經全部實現，分布式鎖也已經講過了。那么，現在應該到數據庫設計及代碼實現階段，我們要注意或准備什么呢？今天先說說商品的數據庫表設計問題吧。
來看看上面的圖片，這個商品的數據庫表怎么設計呢？是不是有人會說，4張表搞定：商品分類表、商品信息表、價格表、屬性表。
沒錯，這樣是可以實現，但存在很多弊端，比如就針對上面的商品（手機），不同的顏色，不同的版本都有不同的價格。按傳統的設計思路，我們把版本作為屬性，不同的屬性對應不同的價格，看似不錯。那顏色又怎么處理呢？是不是不同的版本不同的價格，顏色你就可以隨便選呢？但現實中並不是這樣，同一個版本配置，不同顏色往往都是不同的價格。這又怎么辦呢？你可能又會說我把顏色再設置成一個屬性，顏色和版本兩個屬性組合設置一條價格信息。那如果還有套餐呢？我們繼續這樣搞，是的，完全沒問題。那庫存呢？是否還要放在商品信息表呢？明顯這樣是有問題的。比如榮耀20 版本6G 128G 藍水翡翠 已經賣完了，但這個版本的其他顏色還有貨呀。那數據庫到底怎么設計呢？這就是今天要講的話題。目前的主流解決方案SPU、SKU。
商品的SPU, SKU實現
首先，什么是SPU,SKU呢？
SPU（Standard Product Unit）即標准化產品單元 SPU是商品信息聚合的最小單位，是一組可復用標准化信息的集合。
SKU（Stock Keeping Unit）即庫存量單位 SKU即庫存進出計量的單位，可以是以件、盒、托盤等為單位。
對於電商而言，SPU有一個唯一編碼，一個SPU代表一個產品；SKU為一個產品不同屬性、規格之間的編碼。也就是說，SPU代表產品，SKU代表屬性與規格；一個產品，可以是單屬性產品，也可以是多屬性產品，也就是說一個產品可以有一個SKU，也可以有多個SKU。
那么，針對上面的商品，數據庫表究竟怎么設計呢？
這里是簡單的商品SPU、SKU表設計實現，一共包含六個表。
1，商品分類表
此表添加了parent_id字段，可實現無限層級的樹狀數據結構，parent_id=0表明當前為根節點，否則可使用遞歸算法來遍歷分類下的所有子分類。這里我根據上面圖片中的商品添加了他的基礎分類數據如下：
2，商品品牌表
此表的結構比較簡單，就是品牌的基礎信息。如圖片中的榮耀手機，那么榮耀作為一個手機品牌，添加基礎數據如下：
3，商品表（SPU）
這個表里的每一條數據就是一個標准的產品單元，也就是所謂的SPU。比如榮耀20手機，這就是一個標准的商品，所以我們把它作為一條商品數據存儲。此表必須要包含的字段：商品分類ID，商品品牌ID。注：此表里的商品詳情信息字段，不要直接保存商品的圖文化信息，可以把圖文化信息轉成html靜態文件存儲在文件服務器，然后將存儲的路徑url保存在數據庫此字段里。這樣會在很大程度上節約數據庫開銷。
4，規格表（SKU）
規則表就是這里所謂的商品SKU實現，也就是說這里實現的是商品的存儲單元。針對每一個多屬性的商品，幾個不同屬性的組合將有自己獨立的庫存和價格信息。如上面的榮耀20手機，通過顏色和版本這兩個屬性，組成了以下6條SKU信息。
5，商品屬性key和屬性value
這兩個表作為商品分類的不同屬性存儲，在系統開始運營就需要做數據的初始化。日后運營人員如果要新增某一商品的SKU信息，就可直接根據數據庫的這些基礎數據選取，然后將屬性再以json的形式存儲到對應的規格表。
屬性key:
屬性value：
好了，到此為止商品的SPU、SKU已經說完了。今天我講的這個設計方案，可完全適用於商品類別差異化不大的項目或系統中。但針對差異化較大的情況，那就需要根據自己的業務情況去優化處理。
注：此SpringBoot電商實戰項目的源碼已上傳到github上並已開源，有需要的可以掃碼關注公眾號，然后發送“Springboot”獲取github地址。
掃碼關注公眾號，發送關鍵詞獲取相關資料：
- 發送“Springboot”領取電商項目實戰源碼；
- 發送“SpringCloud”領取cloud學習實戰資料；
