kentzhu：
在電子商務裡，一般會提到這樣幾個詞：商品、單品、SPU、SKU
簡單理解一下，SPU是標準化產品單元，區分品種；SKU是庫存量單位，區分單品；商品特指與商家有關的商品，可對應多個SKU。
首先，搞清楚商品與單品的區別。例如，iphone是一個單品，但是在淘寶上當很多商家同時出售這個產品的時候，iphone就是一個商品了。
商品：淘寶叫item，京東叫product，商品特指與商家有關的商品，每個商品有一個商家編碼，每個商品下面有多個顏色，款式，可以有多個SKU。
SPU = Standard Product Unit （標準化產品單元），SPU是商品資訊聚合的最小單位，是一組可複用、易檢索的標準化資訊的集合，該集合描述了一個產品的特性。通俗點講，屬性值、特性相同的商品就可以稱為一個SPU。例如，iphone4就是一個SPU，N97也是一個SPU，這個與商家無關，與顏色、款式、套餐也無關。
SKU=stock keeping unit(庫存量單位)，SKU即庫存進出計量的單位， 可以是以件、盒、托盤等為單位。在服裝、鞋類商品中使用最多最普遍。 例如紡織品中一個SKU通常表示：規格、顏色、款式。
SKU是物理上不可分割的最小存貨單元。在使用時要根據不同業態，不同管 理模式來處理。比如一香菸是50條，一條裡有十盒，一盒中有20支，這些單位就要根據不同的需要來設定SKU。
老黃的實驗室：
spu，sku，item，規格，單規格商品，雙規格商品，三規格商品…
服裝為例:
一款衣服，是一個spu
這款衣服，有黑白兩個顏色，小中大特大四個尺碼，顏色和尺碼就是他的兩個規格，每個顏色和尺碼排列組合，組成最終的sku。
iphone6為例:
iphone6是一個spu
規格1-顏色，包含黑色白色，土豪金
規格2-容量，包含16G，32G，64G，128G
規格3-制式，移動版，聯通版，電信版
規格4-合約，合約機，非合約機
把每個規格都排列組合一下，就是最終的sku
知乎：有哪些常見的資料庫優化方法？
謝龍：
1.善用explain，看看自己寫的sql到底要涉及到多少表，多少行，使用了那些索引，根據這些資訊適當的建立索引；
2.善用不同的儲存引擎，MySQL有多種不同的儲存引擎，InnoDB，Aria，MEMORY根據需要給不同的表選擇不同的儲存引擎，比如要支援transaction的話用InnoDB等；
3.表很大的時候，做分片。
惑春秋：
資料庫物理層：
1）資料庫系統軟體應該儘量跟資料檔案分置不同儲存裝置
2）如果可能資料庫臨時空間、log儘量使用快速儲存裝置
3）資料檔案應該根據具體應用需要分置不同儲存裝置提高讀取效率
4）資料檔案使用RAID既保障資料安全又有利效能
資料庫邏輯層
1）為資料庫system表空間、user表空間、應用表空間分離
最起碼user和應用不應該使用系統表空間
如果可能三類表空間應該分在不同物理儲存上
2）應用表空間中
表的表空間、索引的表空間也應該分離
3）建立表時應該考慮表的特性
比如有些表大部分時候是隻插入記錄很少修改刪除
有些表是所有記錄經常增、刪、改
有些表只有少數字段
有些表有大量欄位但大部分時候其中大半欄位為空
有些表資料增長很快
有些表資料常年基本不變
等等
不同特性的表應該在建立時定義不同的起始空間和空間增長方案
以儘量讓一條記錄處於一個連續的物理儲存空間提高讀取效率
另外要制定不同的備份恢復和碎片整理機制
4）索引不是越多越好
而是因表的特點而不同
資料變化頻繁的表還應該建立索引定期重建機制
否則索引不但不會改善效能還會降低效能
5）某些應用常用表比如lookup code之類的
如果可能儘量建在獨立的表空間上
並把表空間建在快速儲存裝置上
上面這些對SQL Server一類輕量級的資料庫也就差不多了
但對於Oracle DB2這種重量級資料庫
還有記憶體管理優化
太久不做一時有點兒理不清頭緒了
以後想起來能補再補
資料庫應用層
這個太多了
首先Modeling要合理
這個太重要
應用設計不合理再怎麼優化、誰來優化也只是死馬當活馬病
其次是程式碼中的SQL語句優化
比如查詢儘量使用索引
儘量不要做全表掃描
慎用子查詢和Union All
多表join時儘量用小表去join大表
（注每個資料庫廠商對join的處理不完全一樣
此處的優化應該參考資料庫廠商的使用者手冊）
等等等等
知乎：mysql的資料庫設計到底該不該加約束
比如非空約束，外來鍵約束等。因為我看到我們公司的DBA在設計資料庫結構的時候都是不加任何約束的，這樣對效能的提高有多大，會不會影響到資料的完整性。新手求大牛解答？
joylisten：
學院派會告訴你在設計的時候把應該有的約束都加上
而實踐派得出的結論是主鍵一定加，非空約束儘量加，外來鍵最好依賴於程式邏輯，而不是資料庫，從而更好的擁抱變化，快速響應，資料庫也會有相對較好的效能
Rocky：
主鍵約束一定要加，非空約束必不可少。外來鍵最好不要加，除非是關聯極多，業務極其複雜的時候才可以考慮加外來鍵。
知乎：關於電商網站資料庫的設計？
我在思考一個問題，電商網站的資料庫設計，主要是商品分類，商品的詳情（不同的商品有不同的熟悉，比如衣服有顏色、尺碼，然而電腦有CPU、記憶體、顯示卡等規格)，庫存表（一個商家裡面某個商品有不同的規格，不同的規格有不同的庫存數量），這之間怎麼設計。
可能我描述的不是很清楚，我想了解一下這方面改怎麼設計，可能有朋友問我，為什麼不按照分類吧資料庫設計“死”呢，因為易於之後的擴充套件，我不可能一下子做的很完善，總是慢慢擴充套件的，所以想這麼做。
何明璐：
首先來說對於這種場景有兩種設計方法，這兩種方法都能夠滿足擴充套件性要求
1. 把原有的橫錶轉化為縱表儲存屬性，即
產品表：（product_id, product_name, product_class)
產品屬性表：(product_id, property_id , property_name , property_value)
2. 保持原有橫表設計思路，但是彈性欄位含義單獨後設資料表儲存
產品表：（product_id, product_name, product_class, prop1, prop2, .... propn)
產品屬性含義後設資料表
(product_class , prop1_name ,prop2_name, ..... propn_name)
對於兩種設計方法，個人理解為
a. 對於首頁開啟就必須要能夠快速查詢出來的屬性，而且這些屬性本身各類產品差異不大。而對於差異大的屬性基本都是針對特定一個產品查詢。可以採用方案1來做。
b. 首頁顯示產品列表時候就存在要顯示出不同產品屬性情況，採用方案2來做。當我們處理的是一個product list的時候，由於存在資料表本身的關聯場景，用方案1會比麻煩，也影響效能。
/*********************************************************/
goods_common（公共商品表）
規格和屬性的區別是，規格影響價格，屬性不影響價格，在商品分類頁的是屬性篩選
規格名稱欄位
把規格名稱陣列序列化後存入這個欄位
例如：Array ( [1] => 顏色 )，
key對應的是規格表的id，value對應規格表的名稱
key部分是不會變的，value部分是可以被店鋪填商品的時候修改
規格值欄位
把規格名稱對應的值陣列序列化後存入這個欄位
例如：Array ( [1] => Array ( [222] => 藍色 [224] => 綠色 [225] => 梅紅 [226] => 黑色 ) )，
第一維的key對應規格表id，
二維陣列的key對應規格值表的id，value對應規格值表的名稱
商品屬性
例如：Array ( [206] => Array ( [name] => 款式 [3050] => 毛衣 ) [207] => Array ( [name] => 材質 [3059] => 棉 ))
一維陣列的key對應的是屬性表的id，二維陣列的name對應屬性表的名稱，二維陣列的第二個元素key對應屬性值表id，value對應屬性值表的名稱
商品公共id
商品名稱
商品宣傳詞
商品分類id
商品分類名稱————適度冗餘，減少關聯表
店鋪id
店鋪名稱 ————適度冗餘，減少關聯表
品牌id
品牌名稱
型別id ————關聯型別表，並關聯型別下面的屬性
商品主圖 ————只儲存上傳後圖片的檔名，全路徑通過程式拼接，更靈活
商品內容
商品狀態 ————0 下架，1 正常
違規原因
商品稽核
稽核失敗原因
商品鎖定
商品新增時間
商品上架時間
商品價格
市場價
成本價
折扣
商家自定義編號
運費模版
運費模版名稱
是否推薦
是否免運費
是否開具增值稅發票
一級地區id
二級地區id
店鋪分類id 首尾用,隔開
頂部關聯版式
底部關聯版式
goods（商品主表）
新增不同規格的商品，生成多條商品資訊，sku是不同的，
商品SKUid
商品公共id
商品名稱（+規格名稱）
商品宣傳詞
店鋪id
店鋪名稱
商品分類id
商品品牌Id
商品價格
市場價
商家自定義編號
點選數量
銷售數量
收藏數量
商品規格序列化，例如：Array ( [222] => 藍色 )
商品庫存
商品主圖
商品狀態
商品稽核狀態
商品新增時間
商品編輯時間
一級地區id
二級地區Id
顏色規格id ————關聯商品圖片表，展示顏色圖片
運費模版id
是否推薦
是否免運費
是否開具增值稅發票
店鋪分類id 首尾用,隔開
好評星級
評價數量
spec （商品規格表）
規格id
規格名稱
規格排序
分類id
分類名稱
spec_value （商品規格值表）
規格值id
規格值名稱
規格id
分類id
店鋪id ————不同的店鋪，規格值不同
規格顏色
排序
attribute（商品屬性表）
屬性id
屬性名稱
型別id
屬性值列
是否顯示
排序
attribute_value（商品屬性值表）
屬性值id
屬性值名稱
屬性id
型別id
屬性值排序
category（商品分類表）
分類id
分類名稱
型別id ————新增商品時選擇分類，根據型別id，型別規格表，關聯規格id，取出規格
型別名稱
父級id
排序
標題
關鍵字
描述
type（商品型別表）
型別id
型別名稱
排序
分類id
分類名稱
type_spec（型別規格關聯表）
型別id
規格id
goods_image（商品圖片表）
商品圖片id
商品公共id
店鋪id
顏色規格id ——關聯商品表的顏色id，展示在詳情頁部分
商品圖片
排序
是否預設 ——是否是封面上展示的圖片