目前我們使用購物車的儲存方式主要有：Session方式，Cookie方式，資料庫儲存，我們來一一分析優缺點。

1.Session（Memcached）方式

優點：購物車資訊儲存在服務端，可以儲存1M 資訊。
缺點：對於大型網站會佔有過多的伺服器記憶體資源，造成伺服器壓力過大。Session儲存的資訊會在使用者退出登入後丟失。使用者下次登入，購物車中商品資訊丟失，使用者只能從新選擇。

2.Cookie方式

優點：購物車資訊儲存在客戶端，不佔用伺服器資源，基本可以到達持久化儲存。
缺點：Cookie有大小的限制，不能超過4K，而且不夠安全。如果是個人PC機，Cookie能很好的儲存購物車資訊，但如果是公共辦公環境，Cookie儲存的資訊基本就失效了(會被其他人購物車資訊覆蓋)。對一個大型的電子商務網站，我們需要對使用者的購買行為進行分析，需要對使用者推薦使用者感興趣的商品，如果把購物車資訊儲存在Cookie中，則不能對使用者購買行為分析統計。

3.資料庫儲存

優點：持久化儲存，可以分析使用者購買行為。
缺點: 網站速度變慢，成本和維護增加。

對於一個大型的電子商務網站，我們需要知道使用者對什麼樣的商品感興趣，需要給使用者推薦相似度商品。那麼就有必要分析使用者的購買行為。在這裡只詳細講述下使用資料庫儲存方式的演變。開始我們是使用Cookie儲存購物車的資訊，但使用一段時間後發現有很多客戶投訴，購物車中常常會多了很多商品，而且並不是客戶選擇的商品。資料探勘部門也抱怨不能分析購物車的資訊。。。。我們決定改變購物車的儲存方式。開始我們設計的表是這樣的：

對於登入使用者，我們根據UserId查詢購物車資訊。對於非登入使用者，則根據瀏覽器選擇查詢方式，如果是火狐瀏覽器，我們根據SessionId查詢，如果是IE或360瀏覽器，我們根據IP查詢。在一天訂單量只有幾萬單的時候，系統執行的很穩定。但發現一天訂單量超過10萬單的時候，特別是高峰期，購物車資料庫寫壓力特別大。查詢也時常超時。我們不得不清理儲存時間超過10天的資料。我們新建一個Job每天夜裡執行刪除超過10天的資料。但隨著訂單量的增加。資料庫寫壓力依然很大。這時候我們考慮分庫來解決資料庫的寫壓力。我們根據登入使用者和匿名使用者來拆庫。採用如圖方式

對於登入使用者我們根據UserId拆成2個庫，一個是奇數庫，一個是偶數庫。對於匿名使用者我們根據瀏覽器拆分，火狐瀏覽器（SessionId查詢）一個庫，IE或360瀏覽器（根據IP查詢）一個庫。
對於表結構，我們也做了調整。使用UserId和CreatedDateTicks時間撮做聯合主鍵，登入使用者購物車表結構：

匿名使用者（火狐瀏覽器）儲存表結構：

IE或360瀏覽器儲存表結構：

資料儲存方面我們也做了調整。刪掉了大量的資料庫更新操作，因為大量的更新操作會造成鎖表。購物車資訊發生變化時，Content儲存使用者購物車資訊的XML。現在只需做插入操作了。查詢資料時，返回最後一條資料即可。採用分庫後減輕了單臺數據庫寫資料的壓力，Content儲存購物車資訊的XML避免大量的更新操作。現在系統可以平穩的運行了！

一般來說，可以使用session,cookie和資料庫來記錄購物車資料
1，不過不提倡使用session，這貨佔用伺服器資源，還有過期時間，客戶關掉瀏覽器時session即消失，下次再上來，又得重新選產品。
2，cookie這東西不錯，放在客戶端的，給個一年的過期時間，只要客戶不清掉，每次來都能記得上次的購物車資訊。大家可以看看京東，
在購物車cookie中存了不少東西，有產品編碼和購買的數量等資訊，如京東：yCartOrderLogic={&TheSkus&:[{&Id&:437741$&Num&:2}]}，
原來凡客的cookie中也以JSON的形式存了很多資訊。
所以，我以學習的心態，將產品編碼，價格，名稱，型別和數量等購物資訊做成一個物件，然後物件序列化成JSON，存在客戶端的COOKIE中，
在讀取cookie時，在剛開始的時候很好用，反序列化cookie值成購物車條目物件就可以了，但是當產品型別多起來之後，而且有套裝那種多件產品時，
甚至產品不是來自同一個資料表時，比如普通首飾和鑽石，表的結構都不一樣了，還得到不同的表格中去取，當然首先你得判斷產品型別
這時候一個購物條目物件已經有多條子物件，往往一個查詢中巢狀著兩重以上的迴圈加上多個switch case，當購物車中有十個複雜的條目時，讀取速度
將超過十秒，不管怎麼優化，速度就擺在那裡，不快不慢。。。而且你不能保證客戶不下100個或更多的複雜購物車記錄，最重要的是cookie是有
儲存大小限制的，這種做法有產品很複雜時是不利的，果斷放棄！
3，資料庫這東西好啊，不會像cookie那種容易丟失，也沒有客戶端的限制，你想怎麼存，存多少都行。

購物車資料存資料庫好處有很多，可以分析購買行為，可以為客戶儲存購買資訊（不會因為瀏覽器關閉而丟失）等。
還需要考慮的一個問題是使用者是否登入，淘寶使用的就是cookie記錄，你可以試試，未登入時可以加20個商品，登入後可以加50個，這就是因為
cookie客戶端的限制。
我這裡因為產品線的複雜性，所有購物車條目都儲存在資料庫中。

購物車資料庫設計成兩個關聯表
1，Basket，購物車主表
基本欄位有：BasketId,AddTime,UserId,AddressId,Payment,Status等，不解釋了，看英文意思就行
2，BasketDetail，購物車條目表
基本欄位有：BasketDetailId,BasketId,Type,Code,Qty,ParentId等，ParentId用作子行標識，其它不解釋
兩個表之間使用BasketId做為關聯
當用戶登入狀態時，新增產品到購物時，檢視Basket中是否有Status為True的購物車，沒有則新增一條新的Basket記錄，並將產品資訊相關資料新增至BasketDetail表中
當用戶未登入時，使用cookie記錄一個BasketId值，不往Basket表中插入資料，只往BasketDetail插入資料，其中的BasketId值使用cookie中的BasketId值，當用戶登入
後，檢視Basket中是否有Status為True的購物車記錄，有則合併（更新cookie和BasketDetail中的BasketId為查詢出來的Basket表中的BasketId值），無則新增一條新的
Basket記錄，並將BasketId值置為Cookie中記錄的basketid值