關於b2c官網產品分類屬性解決方案思路
一：為什麼要做分類多屬性？
1、**架構的清爽性，可維護性，分類搜尋
在一些比較大型的b2c**，會發現不同的類目下面都會有一些不同的選項
例如進入了紅酒櫃類目，我可以選擇是 多少瓶的 ，電子的還是壓縮機的 ，**範圍等
如果進入了攪拌機的類目，我可以選擇多少轉的，功率，產量多少等
但如果是傳統的屬性表結構的話，將是這樣儲存
產品表：
名稱，產品編碼，型號，瓶數，壓縮機型別，**，轉速，功率，產量
這樣做的話 每乙個產品都記錄著這麼多的資訊，而且很多資訊都不是自己想要的
例如紅酒櫃的時候不需要轉速的資料，攪拌機不需要壓縮機型別的資料
則存在十分多的資料冗餘，更可怕的是，我們的產品分類幾百種，如果都按傳統的設計方式去實現的話，則難以
管理而且在前台設計的時候也不好做，十分每乙個分類的都要有乙個專門的class ?明顯這種設計不大科學從系統
的維護性來說是不可取的
2、資料對比的實現：
在太平洋電腦網裡面有個很好的功能，就是導購對比功能，如圖
在我們聖托的產品不同於凡客，和京東
我們更多的是屬於非標準的產品，還不屬於家喻戶曉的大品牌，
共10多萬個產品，且種類繁多
那如何才能讓顧客快速的選擇出符合自己的產品呢？
我們也許可以定下一些行業標準，例如什麼引數的產品質量更好，更合適哪類人群使用···
這裡如果有乙個如太平洋的對比功能就好很多了
二、如何實現分類多屬性
1、資料結構：
我們知道，我們的產品可以進行分類，從物件導向的角度來說，我們的子類應該是繼承於父類的，例如男人繼承於人類所以，男人應該擁有人類所有的屬性。
so：分類表中可以新增乙個字段，記錄在這分類中的屬性名，用json序列化儲存到表字段中，子級分類亦然。
如因為 json可以轉換為array，所以我們的屬性集將成為array的格式，最終所屬類目的產品的屬性則為所屬類目以及其所有父級分類的並集。
如果從資料結構來說，我們可能會考慮得更嚴謹一些，不是轉化為array而是乙個tree裡面
並在產品表中新增乙個命名為ex_attr的欄位名，對應屬性集中的每乙個屬性，並以json的格式進行儲存入錶中。
例如當然如果我們的類目想更多的功能，顯示的更獨特性的話 我們的json格式就可以儲存為
[,]json可以直接轉化為tree 和 tree_item
發到園區，也是為了大家能拍拍磚，給點意見 謝謝
當然，這種設計還是一種思想。
希望這種思想能在下一版的系統改進中實現出來
#1樓[ 樓主]
2011-07-15 15:43 |
肖希明很多地方比較跳躍性，也是考慮到大家的水平應該懂得我在講什麼
支援(0)
反對(0)
#2樓2011-07-15 16:38 |
沉默楊仔
雲裡霧裡.沒看懂.
支援(0)
反對(0)
#3樓2011-07-15 16:49 |
it鳥搜尋的時候方便嗎?
支援(0)
反對(0)
#4樓[ 樓主]
2011-07-15 17:04 |
肖希明這也是我考慮的問題之一
我的打算是這也解決這個問題的：
例如我要搜尋轉速為10000/m 的產品
那麼我搜尋的時候則會用 like "%'轉速':'10000/m'%" 這樣的語句，當然，這樣的解決方案並不是無敵的，例如我要搜尋轉速在10000以上的話
這個設計就有點困難了，更多可以用在列舉型或者字元型的資料裡面
支援(0)
反對(0)
#5樓2011-07-15 17:09 |
it鳥所有屬性乙個表,在產品總表裡面可以in(1,2,3...)
支援(0)
反對(0)
#6樓[ 樓主]
2011-07-15 17:18 |
肖希明不是很理解您的意思，您是指用陣列儲存所有屬性的編號嗎，儲存在產品表裡面？
關於上文
還有就是關於公共屬性的提取，我們都知道，乙個產品都有**，重量，尺寸 等通用的屬性，那這些屬性就不用用這種麻煩的方式去儲存，而是用傳統的方式，提高效率並減少儲存空間
支援(0)
反對(0)
#7樓2011-07-15 18:29 |
沈融興很多開源的商場系統可以借鑑的....我研究了很長一段時間的ecshop產品屬性表...說實話...做這個真的挺繁瑣的...
支援(0)
反對(0)
#8樓2011-07-15 18:42 |
redspear
常用的不都是變列為行嗎，這種情況可以借鑑部落格系統的文章表和tag表的設計模式。用json，和用序列化字段沒有什麼區別，查詢時候你就悲劇了。
支援(0)
反對(0)
#9樓2011-07-16 13:57 |
ie421
我這有乙個成熟的方案，可以解決閣下的問題：思路如下：採用執行時自定義型別，自動生成表的方式。如自定乙個產品的基類，存放公共的屬性，如果需要定義特別型別的子類，則採用自定型別屬性的方式，並自動生成子類的資料表來存放，這樣這個特別的子類的資料就分別存放在兩個表，乙個為產品基類表和特殊子類表。在查詢時，需要用到自定義結構查詢體系，將這兩個表聯合起來查詢，並返回所有資料。
這方案的好處是：可以自定義各種型別的屬性，並且每乙個型別都有特定的表來存放，每乙個屬性都有唯一的字段來儲存，在查詢，排序等功能非常方便。
不足的地方（或者叫難點）：每定義乙個子類都需要生成一資料表，需要額外的**來維護子類的屬性列表和資料表的生成，在查詢時，由於是執行時生成的table，固查詢方面也需要乙個自定義查詢框架來查詢。每一種型別會生成乙個表，會導致乙個db中產生很多自定自定義的table（會非常之多，有好幾百個，取決於系統中的型別的多少），有些公司不允許這種搞法，特別是dba的反對。
總的來講：這個方案就是執行時設計方式。其實整體技術難度並不大，我用這個方案已做了好幾個專案的應用。如erp系統的物料主檔（不同型別的物料主檔有不同的屬性，顯示的物料列表也顯示不同的字段，可排序等，可按自定義欄位來模糊或精確查詢）。檔案館系統的文件型別。srm系統的採購定單，**單等（不同型別的物料，顯示不同屬性的採購規格和**規格等）等等。
感興趣的朋友可以和我來交流一下。
e-mail:[email protected]
思科轉型 網真模式下探B2C
近日，中國首個 思科網真演播室 在中國人民大學明德新聞樓落成。這標誌著乙個由資訊產業機構 專業新聞機構和新聞教育機構聯合打造的集產學研功能為一體的現代技術平台在中國的出現。帶有新聞界的敏感，落戶人民大學的新聞專業，意義深遠。根據思科發表的宣告，該演播室由思科公司攜手 電視台和中國人民大學打造，三方將...
B2C電商設計
set names utf8mb4 set foreign key checks 0 create table category id int 11 not null primary key auto increment,name varchar 255 not null default comme...
來自paidai的b2c經驗
www.paidai.com 輕電子，重商務。web端是表現，鏈是核心。b2c五大因素 服務 庫存 速度 web端的使用者體驗。零售永遠是乙個精打細算的生意，更高的運營效率，更低的運營成本。在rma反向物流中，售後和客服是業務部門，其它部門是服務支援部門。滑鼠 水泥 和 水泥 滑鼠 天壤之別，搞清楚...