這兩天公司要做一個商城專案，網上搜了很多沒找到完整的、有結構體系的資料，可能這件事本身並不難，但是對新手非常不友好，所以我藉機把這些碎片化的資料嘗試整理成一個有體系的資料，希望能對你有幫助。資料來源包括：
資料庫設計
先亮出我最終的workbench設計稿： workbench資料連結
其實不復雜，也只是完成了最基本的功能——賣商品。
下面詳細說下我設計過程中的思路和知識點。
商品相關
SKU和SPU
SPU全稱Standard Product Unit，最小包裝單元；SKU全稱Stock Keeping Unit，最小主要單元。比如堅果R1是SPU，而堅果R1 64G 細紅線版可以稱為一個SKU，SKU也可以看做最小銷售單元。我對此的理解是SKU=SPU+規格。SKU和SPU是一對多關係，SPU和規格是一對一關係。
規格
規格是細化SPU為SKU的標準。比如顏色、記憶體等。規格可以用於篩選商品，比如下圖中京東對手機的篩選條件，這些都是規格，跟規格類似的有個概念叫屬性。
屬性
商品屬性，也可以叫商品詳情。主要用於展示和介紹商品。和規格有一定重合性，比如重量，顏色等。但他倆最大的區別，規格用於篩選，屬性用於展示。我把規則設計成表，把屬性設計成MySQL的text欄位，用json儲存。一個SKU可以用多個屬性和多個規格。
規格值
當時這裡沒搞懂，就多寫了點。
規格表中存的是像顏色、記憶體這些，而規格值表中存的是黑色、32G。更具體的說，規格表中的資料類似於規格名稱、規格id、規格順序、規格錄入方式（比如記憶體通常有規定的選項；而顏色不好窮盡，通常讓人手動加）、檢索方式（例如不檢索、關鍵字、範圍檢索等）；而規格值表通常就規格表id和規格值。規格表和規格值表是一對多關係，而規格表和SKU是多對多關係。
品牌
規格的圖中，我沒有把品牌劃到紅框內，因為品牌不存在規格表中，但品牌可以看做一種特殊的規格，它是一個篩選條件，品牌相比普通規格，擁有更多屬性同時也更復雜，比如品牌名稱、logo、故事等；品牌還可以和SKU關聯。所以我把品牌單獨設計成表。品牌和SKU是一對多關係。
商品分類
商品分類和商品型別也是兩個容易混淆的概念。商品分類的目的是為了人們方便挑選；而商品型別≈商品規格，目的精細篩選。兩者都是選擇條件，區分點在於分類是模糊和精準。下圖就是商品分類，商品型別可以參考上面的規格圖。我把商品分類設計成一張單獨的表，商品分類表和SKU是一對多關係。從資料庫層面講，商品分類是在商品分類表中選SKU，而商品型別是在眾多SKU中根據規格篩選。
經銷商店鋪
就像京東上不僅有自營，還有第三方店鋪的商品。不管是自營還是經銷商店鋪，本質都是店鋪。店鋪只用跟SPU關聯即可。所以我建了一張店鋪表，店鋪和SPU是一對多關係。
庫存相關
庫存表
每個SPU都有對應的庫存，所以SPU和庫存表是一對一關係。
訂單相關
訂單
就像開頭說的，前期的核心是賣商品，所以訂單這塊不涉及活動。訂單表中只包含訂單相關的屬性，比如訂單狀態、訂單金額等，訂單表和SPU是一對多關係。
購物車相關
購物車
同理，購物車表和SPU也是一對多關係。
資料庫設計總結
商城可以設計的很複雜，還可以增加活動、秒殺、推廣、物流、運維、發票、支付等等等等，但前期專案剛建立的核心只有一個——賣商品。後面這些東西我會再慢慢增加，即將增加的是很重要的專案架構設計。歡迎收藏，我會及時更新。也歡迎評論，畢竟這些東西只看了一晚上就寫下了，可能有些不對的地方，還望賜教。