[產(chǎn)品設(shè)計]電商設(shè)計知乎總結(jié)，產(chǎn)品設(shè)計電商總結(jié)

?

想做一個B2B2C的電商平臺，在后臺數(shù)據(jù)統(tǒng)計搭建的時候需要注意哪些問題？如何設(shè)計具體的統(tǒng)計模塊？

?

王于萍：

我認(rèn)為在建數(shù)據(jù)庫前，需要設(shè)計好的，是需求和流程，有了這一步的需求，你就知道了在這里你需要什么數(shù)據(jù)；有了流程，你就知道了你能得到什么數(shù)據(jù)，甚至于數(shù)據(jù)類型。

比如供應(yīng)商管理，你會得到供應(yīng)商的公司地區(qū)、電話、類目等，在數(shù)據(jù)統(tǒng)計中，你可以對地區(qū)、類目統(tǒng)計，再根據(jù)C的對應(yīng)需求推薦等

?

?

PalmWong：

建議先從業(yè)務(wù)理解開始：

BBC平臺，首先分成三個后臺

商家門戶+平臺運營門戶+買家個人門戶

?

要做統(tǒng)計的部分同樣是三塊：

1、消費者個人視角出發(fā)：個人的消費統(tǒng)計

2、平臺運營的視角出發(fā)：整個平臺的運營情況統(tǒng)計，針對商家的運營情況統(tǒng)計

3、商家視角出發(fā)的統(tǒng)計

?

BBC商城其實是非常復(fù)雜的業(yè)務(wù)系統(tǒng)，因為角色和功能的變化，導(dǎo)致其中數(shù)據(jù)交互其實非常多。且對賬、統(tǒng)計、權(quán)限管理異常情況很多。

?

不是看著天貓的模式，就閉著眼睛可以做的。

?

用 PHP+MySql 架構(gòu)用戶數(shù)和訪問量為千萬級別的類似淘寶商城那樣的 B2C 網(wǎng)站，如何？

?

Dion：

系統(tǒng)架構(gòu)很重要！

?

語言：

主流語言都沒什么問題。PHP、Java什么的都行。

?

前端服務(wù)器：

如果有條件CDN，最好。沒有的話，一定要保證前端的負(fù)載性能。一般推薦Nginx。

?

應(yīng)用服務(wù)器：

集群唄。前端負(fù)責(zé)負(fù)載均衡。集群的話，Session的問題注意下就行。別的沒什么。

?

數(shù)據(jù)存儲：

如果數(shù)據(jù)量比較大的話（百萬級），用MySQL + Memcached做集群沒問題。

如果數(shù)據(jù)量再大的話，考慮NoSQL吧。比如Facebook用Cassandra，Amazon用Dynamo。

?

socici：

你可以簡單點，從用戶訪問的數(shù)據(jù)角度看

靜態(tài)文件,包括圖片、HTM 、JS、css 這些不經(jīng)常變的數(shù)據(jù)。 單獨給個域 如http://static.xxxx.com 由nginx管理

通過前后臺發(fā)布的動態(tài)數(shù)據(jù)，分以下幾種：

讀的數(shù)據(jù)：

1.需要用戶查詢的大數(shù)據(jù)，如訂單之類的，可以去查slaver的數(shù)據(jù)庫

2.系統(tǒng)公共頁面顯示的數(shù)據(jù)，如部分商品信息、排行榜之類的可以去緩存里取

寫的數(shù)據(jù)：

要求即時生效的，如修改用戶信息，直接同步寫到master數(shù)據(jù)庫

即時要求不高或者有并發(fā)限制的，如發(fā)微博、發(fā)私信之類的 先寫到隊列，異步讀取保存到數(shù)據(jù)庫

?

電商平臺中商品規(guī)格設(shè)計的問題，拋出，求吐槽？

?

商品表（商品名稱、價格、上下架等一些商品基本的信息）

例如：1、 手機、100

規(guī)格表（主鍵、商品ID、規(guī)格名稱 ）

例如：1 、1、運營商

商品規(guī)格值表（主鍵、規(guī)格ID、商品ID、規(guī)格值ID、規(guī)格值NAME）

例如：1、1、1、0、電信版

2、1、1、1、移動版????

規(guī)格庫存表（商品ID、規(guī)格值ID組合、規(guī)格值NAME組合、庫存量、價格）

例如：1、1/0(運營商、電信版)、運營商/電信版、100個、100塊

?

問題描述：

?

以上方式可實現(xiàn)多規(guī)格多庫存但是采用一種約定的規(guī)格順序，感覺在編寫程序時，系統(tǒng)在后期統(tǒng)計不同規(guī)格相關(guān)的數(shù)據(jù)就會很痛苦。

并且在實現(xiàn)商品創(chuàng)建時，要先把商品創(chuàng)建好后，才能創(chuàng)建規(guī)格，個人參考一些大的電商平臺方式，發(fā)現(xiàn)都是一個提交完成商品創(chuàng)建。

?

需要的幫助：

?

需要結(jié)合我的問題描述，給一個合理的商品多規(guī)格、多價格、多庫存的設(shè)計方案，來解決我編程上的復(fù)雜度，同時保證我可以在商品創(chuàng)建的交互設(shè)計中簡單。

?

socici：

商品分類 （類型id,類型名稱，父ID）

商品表（商品名稱、價格、上下架等一些商品基本的信息、商品分類）

?

規(guī)格表（主鍵、規(guī)格名稱 ）

規(guī)格值表（規(guī)格值ID、規(guī)格id、規(guī)則值類型、規(guī)格默認(rèn)值）

規(guī)格-分類關(guān)聯(lián)表（商品分類id，規(guī)格id)

?

商品-規(guī)格關(guān)聯(lián)表(商品id,規(guī)格id,規(guī)格值ID,規(guī)格實際值）

?

庫存表（商品id,數(shù)量,價格)

?

類似淘寶關(guān)于產(chǎn)品詳情頁的數(shù)據(jù)庫存儲是怎么存儲的呢？

?

1，每個產(chǎn)品的 圖片數(shù)和介紹的段落數(shù)都是不固定的,是采用編輯器編輯好之后生成html整個存儲到數(shù)據(jù)庫么？不現(xiàn)實吧？

2. 要是以數(shù)據(jù)庫字段存儲到話,每個產(chǎn)品的 圖片數(shù)和介紹的段落數(shù)是不固定的,就算設(shè)置一個上限,那也會浪費很多字段啊

3.在查詢的時候,如果圖片和介紹文字是分開存儲的,那么在查詢之后頁面展示的時候是怎么 將某一圖片和關(guān)于介紹他的問題相匹配的呢

?

劉傳雙：

總體來說

1、商品的結(jié)構(gòu)化信息保存在數(shù)據(jù)庫，名稱、價格、庫存、屬性等，當(dāng)然不是簡單的一張表。

2、商品的非結(jié)構(gòu)化信息保存成小文件，存儲在自主開發(fā)的海量小文件系統(tǒng)中，圖片和商品描述信息。

3、商品的圖片文件id需要存儲在數(shù)據(jù)庫或者其他類型的存儲的，不一定非要多個字段，這是水平方式，一般把商品的一個圖片存儲為一條記錄，縱向擴展。

4、文檔在存儲之前，先保存圖片，并把文檔中的圖片src地址替換為小文件系統(tǒng)中的圖片路徑，就可以了

?

補充一句，不能把存儲理解成只有數(shù)據(jù)庫和文件系統(tǒng)，存儲有各種類型的，不同的文件系統(tǒng)、各種RDBMS、NoSql存儲……

?

子柳：

其實幾位同事已經(jīng)回答了，我再從歷史的角度做個補充

最早這個字段確實是放在數(shù)據(jù)庫里面的，是一個clob字段，存放的就是html的片段。而且當(dāng)時這個字段跟商品的標(biāo)題、價格、賣家ID等等是在一個表里面的，性能會受到多大影響是可以想象的。

所以這種方式是注定長久不了的，我在2005年，把這個字段單獨分離出來一張表來存放了，這沒多少技術(shù)含量，當(dāng)時卻給數(shù)據(jù)庫減輕了很大壓力，DBA們很感謝我。

在2006年以后，淘寶開始大規(guī)模的采用緩存，這個字段也放進(jìn)了緩存里面，于是這又給數(shù)據(jù)庫減輕了很大壓力（只有不在緩存里的數(shù)據(jù)，才去數(shù)據(jù)庫里面讀取，讀出來就放入緩存了）。

到了2007年，淘寶開發(fā)了分布式文件存儲系統(tǒng)TFS，于是就徹底的把這個字段請出了數(shù)據(jù)庫，一同請出的還有交易快照這樣的大字段信息。

?