從淘寶數據結構來看電子商務中商品屬性設計
為什么要這樣設計
先說幾個需求，看看您現在是如何去實現：
一個用戶來到我們網站,在前臺頁面,
1.他要買洗發水，他進入了洗發水的類別，他想買帶去屑止癢功效的500ml的洗發水，能否直接搜索出來所有品牌帶這個功效屬性是500ml的洗發水
2.接著他要買一件T恤，他想買V領，短袖的T恤，能否直接通過2個屬性搜索出所有品牌的T恤展示給他
3.他進入一個T恤的詳情頁面，由于白色賣的比較好，所以白色會比其他顏色貴一些，所以他選擇不同顏色+不同尺碼的搭配，就會顯示出不同的價格以及是否有庫存
后臺：
1.統計某些商品某種屬性銷量情況和庫存，反饋給倉庫部門及時備貨，比如海飛絲去屑系列的250ml的洗發水在這個系列中賣的最好，300ml的其次。A品牌XX大衣紅色XL時間段內的銷量和庫存量。
2.這個洗發水在做一個階梯價銷售，買2瓶便宜2塊，買3瓶便宜5塊，需要給出這種組合的銷售量數據給策劃人員來說明階梯價銷售對消費者的影響
3.A品牌T恤分圓領，V領，7分袖，短袖，統計圓領和V領銷量情況供買手或者設計師參考大眾比較接受什么設計，以備下一次的采購。
4.這一年做了幾十個活動，每個活動做了很多單品的搭配組合銷售，比如500ml某種洗發水+黃色的眼霜等，我們現在沒有做數據倉庫和數據分析，那么要求sql語句來得到那種單品的銷量情況，讓我們可以能得知策劃者的搭配到達了什么樣的效果。
甚至變態一點，我們要統計我們店得面膜的銷售，我要知道撕拉型的面膜，水洗式面膜，睡眠免洗式面膜中帶美白功能，帶抗皺功能，帶控油功能等哪種賣的好一些，怎么辦呢？
順便扯一句，根據商品放置在頁面的位置，深度，銷量可以分析出某些品牌商品不需要放置在重要位置，某些對于我們來說利潤高一點，或者銷量不是很理想的商品放在重要位置或者排序在前來提高用戶瀏覽量進而提高購買率。
如果不設計屬性，這種搜索是很難進行的！如果不分的這么徹底，比如ecshop或者nopecomerce,那么你無法針對每個SKU設置組合搭配的價格和數量以及商家編碼和SN號。
上一篇設計出現的問題以及解決辦法
在上一遍文章中，有比較大的問題沒有解決:
1.商品錄入編輯界面編碼實現過于復雜
2.如何通過屬性搜索
3.按現在屬性值屬性表設計無法做到，如果A品牌洗發水有去癢止屑功效，B品牌洗發水同樣有這個系列，無法搜索具有去癢止屑功效屬性的所有洗發水的銷量，因為現在的屬性名和屬性值表是1：N的關系，應該是N:N的關系
解決問題1：最簡單的實現商品的錄入界面:
在這里，我把商品的品牌和系列這個麻煩的東西分開了，為什么分開：品牌和系列導致2個屬性名表和屬性值多級引用，在實際代碼實現過程中也會增加很多代碼，增加復雜性.由于項目原因，這里只做了父子及關系，您在設計的時候，這里應該是品牌一張表，系列是父子及，有第3張表記錄品牌與系列的多對多關系。為什么呢，只有這樣，才能滿足比如A洗發水有去屑止癢系列，B洗發水同樣也有這個系列，那么才能方便的統計出去屑止癢洗發水的總的銷售情況！
解決問題2.通過屬性搜索
1.首先說明這個SKU和屬性如何存儲
在添加一個商品的時候，在pg_items表中保持商品的基本信息.
pg_item_sku表中保存sku信息，這個sku信息用來實現頁面上的選擇顏色，尺碼這種組合不同價格，或者洗發水選擇不同毫升數不同價格。
pg_item_attr表中保存所有屬性信息，包括每個SKU的屬性拆分之后的信息，這樣的話，保證能通過每種屬性來搜索商品。
比如我要搜索帶有滋潤功能的200ml的沐浴露，那么我的語句就是：
SELECT DISTINCT(dbo.pg_items.item_id),pg_items.name FROM dbo.pg_item_attr pa
INNER JOIN dbo.pg_items ON pg_items.item_id = pa.itemid
INNER JOIN pg_item_attr pa2 ON pa.itemid = pa2.itemid -- 組合
WHERE pa.p_id=772167869 AND pa.v_id=1866712003
AND pa2.p_id = 1419662919 AND pa2.v_id = 758727405 -- 組合
我的做法是，通過屬性值ID和屬性名ID的組合組合成上面的語句，有多條就組合多次,這里按照我們一般的情況，是不會說組合到級聯10幾次的，如果您覺得不靠譜，歡迎提出出您的看法。
解決問題3.統計相同特性的不同商品的銷售情況
如通過洗發水功效，服裝的花色，衣領的樣式來分析特性的不同對銷售的影響.要實現在屬性名和屬性值表的設計的時候，應該是有第三張關系映射記錄表來記錄多對多關系。我這里還是偷懶了，因為我是針對淘寶的系統，拉下的屬性已經是把3張表打橫成了2張表，正好不用自己做了。如果是自己做系統，那就得考慮加上關系映射表.
這樣設計的缺點
1.實現復雜
2.需要商品維護人員對自己商店賣的各種商品的屬性，注重的統計的方面有個比較清晰的認識，學習成本高一點
3.策劃，業務人員必須理解這樣的設計，才能結合系統給決策帶來所需要的數據
我覺得程序員應該對業務的理解僅次于項目的策劃人和需求分析人員甚至比他們對某些商業模式更為理解，深入行業，了解行業的點點滴滴，有敏銳的需求的嗅覺，那么才能做出好的程序。而且程序是為業務服務的，如果不深入了解業務，那么很多時候程序會偏掉，舉一個簡單的列子，現在某衣服做一個活動，上午是200塊，下午是150塊，在晚上是100塊，那么這個價格變動帶來的銷量就能給活動策劃者提供強有力的數據支撐，我們也能學到背后的商業模式，為什么要這樣做，如何做?。ㄙ嵢藲猓蛟毂?，清倉等）不然就寫幾行代碼，搞搞表關系，有什么意思？？其實里面的各種調調，比幾行代碼有意思太多了!
原文鏈接：http://www.cnblogs.com/mmmjiang13/archive/2011/08/03/2125640.html
【編輯推薦】
