想做一個B2B2C的電商平台，在後台數據統計搭建的時候需要注意哪些問題？如何設計具體的統計模塊？
王於萍：
我認為在建數據庫前，需要設計好的，是需求和流程，有了這一步的需求，你就知道了在這裡你需要什麼數據；有了流程，你就知道了你能得到什麼數據，甚至於數據類型。
比如供應商管理，你會得到供應商的公司地區、電話、類目等，在數據統計中，你可以對地區、類目統計，再根據C的對應需求推薦等
PalmWong：
建議先從業務理解開始：
BBC平台，首先分成三個後台
商家門戶+平台運營門戶+買家個人門戶
要做統計的部分同樣是三塊：
1、消費者個人視角出發：個人的消費統計
2、平台運營的視角出發：整個平台的運營情況統計，針對商家的運營情況統計
3、商家視角出發的統計
BBC商城其實是非常復雜的業務系統，因為角色和功能的變化，導致其中數據交互其實非常多。且對賬、統計、權限管理異常情況很多。
不是看著天貓的模式，就閉著眼睛可以做的。
用 PHP+MySql 架構用戶數和訪問量為千萬級別的類似淘寶商城那樣的 B2C 網站，如何？
Dion：
系統架構很重要！
語言：
主流語言都沒什麼問題。PHP、Java什麼的都行。
前端服務器：
如果有條件CDN，最好。沒有的話，一定要保證前端的負載性能。一般推薦Nginx。
應用服務器：
集群呗。前端負責負載均衡。集群的話，Session的問題注意下就行。別的沒什麼。
數據存儲：
如果數據量比較大的話（百萬級），用MySQL + Memcached做集群沒問題。
如果數據量再大的話，考慮NoSQL吧。比如Facebook用Cassandra，Amazon用Dynamo。
socici：
你可以簡單點，從用戶訪問的數據角度看
靜態文件,包括圖片、HTM 、JS、css 這些不經常變的數據。 單獨給個域 如http://static.xxxx.com 由nginx管理
通過前後台發布的動態數據，分以下幾種：
讀的數據：
1.需要用戶查詢的大數據，如訂單之類的，可以去查slaver的數據庫
2.系統公共頁面顯示的數據，如部分商品信息、排行榜之類的可以去緩存裡取
寫的數據：
要求即時生效的，如修改用戶信息，直接同步寫到master數據庫
即時要求不高或者有並發限制的，如發微博、發私信之類的 先寫到隊列，異步讀取保存到數據庫
電商平台中商品規格設計的問題，拋出，求吐槽？
商品表（商品名稱、價格、上下架等一些商品基本的信息）
例如：1、 手機、100
規格表（主鍵、商品ID、規格名稱 ）
例如：1 、1、運營商
商品規格值表（主鍵、規格ID、商品ID、規格值ID、規格值NAME）
例如：1、1、1、0、電信版
2、1、1、1、移動版
規格庫存表（商品ID、規格值ID組合、規格值NAME組合、庫存量、價格）
例如：1、1/0(運營商、電信版)、運營商/電信版、100個、100塊
問題描述：
以上方式可實現多規格多庫存但是采用一種約定的規格順序，感覺在編寫程序時，系統在後期統計不同規格相關的數據就會很痛苦。
並且在實現商品創建時，要先把商品創建好後，才能創建規格，個人參考一些大的電商平台方式，發現都是一個提交完成商品創建。
需要的幫助：
需要結合我的問題描述，給一個合理的商品多規格、多價格、多庫存的設計方案，來解決我編程上的復雜度，同時保證我可以在商品創建的交互設計中簡單。
socici：
商品分類 （類型id,類型名稱，父ID）
商品表（商品名稱、價格、上下架等一些商品基本的信息、商品分類）
規格表（主鍵、規格名稱 ）
規格值表（規格值ID、規格id、規則值類型、規格默認值）
規格-分類關聯表（商品分類id，規格id)
商品-規格關聯表(商品id,規格id,規格值ID,規格實際值）
庫存表（商品id,數量,價格)
類似淘寶關於產品詳情頁的數據庫存儲是怎麼存儲的呢？
1，每個產品的 圖片數和介紹的段落數都是不固定的,是采用編輯器編輯好之後生成html整個存儲到數據庫麼？不現實吧？
2. 要是以數據庫字段存儲到話,每個產品的 圖片數和介紹的段落數是不固定的,就算設置一個上限,那也會浪費很多字段啊
3.在查詢的時候,如果圖片和介紹文字是分開存儲的,那麼在查詢之後頁面展示的時候是怎麼 將某一圖片和關於介紹他的問題相匹配的呢
劉傳雙：
總體來說
1、商品的結構化信息保存在數據庫，名稱、價格、庫存、屬性等，當然不是簡單的一張表。
2、商品的非結構化信息保存成小文件，存儲在自主開發的海量小文件系統中，圖片和商品描述信息。
3、商品的圖片文件id需要存儲在數據庫或者其他類型的存儲的，不一定非要多個字段，這是水平方式，一般把商品的一個圖片存儲為一條記錄，縱向擴展。
4、文檔在存儲之前，先保存圖片，並把文檔中<img>的圖片src地址替換為小文件系統中的圖片路徑，就可以了
補充一句，不能把存儲理解成只有數據庫和文件系統，存儲有各種類型的，不同的文件系統、各種RDBMS、NoSql存儲……
子柳：
其實幾位同事已經回答了，我再從歷史的角度做個補充
最早這個字段確實是放在數據庫裡面的，是一個clob字段，存放的就是html的片段。而且當時這個字段跟商品的標題、價格、賣家ID等等是在一個表裡面的，性能會受到多大影響是可以想象的。
所以這種方式是注定長久不了的，我在2005年，把這個字段單獨分離出來一張表來存放了，這沒多少技術含量，當時卻給數據庫減輕了很大壓力，DBA們很感謝我。
在2006年以後，淘寶開始大規模的采用緩存，這個字段也放進了緩存裡面，於是這又給數據庫減輕了很大壓力（只有不在緩存裡的數據，才去數據庫裡面讀取，讀出來就放入緩存了）。
到了2007年，淘寶開發了分布式文件存儲系統TFS，於是就徹底的把這個字段請出了數據庫，一同請出的還有交易快照這樣的大字段信息。
