耳根,古风名字

主頁 > 知識庫 > 一些關(guān)于asp 購物車的想法

一些關(guān)于asp 購物車的想法

問題： 1.購物車中的數(shù)據(jù)是否應(yīng)該存儲在數(shù)據(jù)庫中？
我特別想知道在真正的項目中，那些真正的軟件工程師是如何考慮這個問題的。在Google上一搜，搜到了一篇咱園子里一位網(wǎng)友的觀點：購物車應(yīng)該是個臨時存儲數(shù)據(jù)的模塊，他將其存放在Session對象中。這位網(wǎng)友說的很有道理，不過我并不喜歡這樣的做法。如果大家都將其存儲在Session對象中，成千上萬個用戶一同購物的話，想必ASP.NET服務(wù)器必將承受巨大的負載。也許像我們國內(nèi)的網(wǎng)站可能會好一些，但想Amazon這樣的網(wǎng)站，怎么做的呢？Amazon中國網(wǎng)站，也就是Joyo的網(wǎng)站，并不是將其存儲在Session對象中，因為我如果這次放入購物車中的商品沒有提交訂單，下次登錄后購物車中還會有這些商品。因此，我想他們可能是將這些購物車中的數(shù)據(jù)放入了數(shù)據(jù)庫中。
回復(fù)：把購物車存放在Session中，這種做法似乎只存在于大學(xué)里的課程設(shè)計或者一些無人在意的實習(xí)項目中出現(xiàn)。事實上，基本所有的電子商務(wù)網(wǎng)站都把購物車數(shù)據(jù)存放到了數(shù)據(jù)庫里。下面是一些解釋和設(shè)計上需要注意的地方：
1、Session并不適合做大數(shù)據(jù)量的數(shù)據(jù)存放，當(dāng)用戶比較多的時候勢必影響服務(wù)器性能，這是應(yīng)該避免的。
2、Session存在意外丟失的問題，或者當(dāng)用戶不小心關(guān)閉瀏覽器，都會引起購物車內(nèi)物品全部丟失，用戶體驗很不好
3、Cookies可以解決上面一條里Session的問題，但是Cookies的長度限制，以及使用Cookies時的通訊開銷，還有安全性方面考慮，Cookies并不適合做購物車
4、比較好的用戶體驗是，無論用戶登錄與否，都可以在一定時間內(nèi)記錄購物車狀態(tài)，這就要求數(shù)據(jù)庫內(nèi)購物車不能與用戶捆綁太死
5、放到購物車里的商品，一般都是有購買意向的商品，但并不一定會成為真實的訂單，這時候，保留這份數(shù)據(jù)，對數(shù)據(jù)挖掘、業(yè)務(wù)分析有至關(guān)重要的作用
問題： 2.關(guān)于并發(fā)？
原來我在開發(fā)自己的模擬網(wǎng)站的時候，曾經(jīng)想到這樣一個問題：如果一個客戶在網(wǎng)站將一些圖書放入了購物車，那么這些數(shù)量的圖書是否應(yīng)該從庫存中減去呢？當(dāng)時我是這樣做了。我將購物車中相應(yīng)圖書的數(shù)量從數(shù)據(jù)庫中減去，以防止此時其他用戶看到”虛”的庫存數(shù)量（如果沒有減去，那么其他用戶是可以購買的。例如：庫存中圖書的數(shù)量是10本，客戶A將10本放入自己的購物車，此時客戶B也將10本放入自己的購物車，那么誰將購買到此書將成為一個矛盾）。不過我這樣做的結(jié)果是，每當(dāng)客戶更新購物車的同時就會同數(shù)據(jù)庫有一次交流，加大了數(shù)據(jù)服務(wù)器的負擔(dān)。Amazon.cn在這方面做的也不是很好，前些日子相信大家可能都遇到了當(dāng)購買《深入理解操作系統(tǒng)》一書的時候，本來生成了訂單，但是卻在第二天告知缺貨的事情。這一事件確實非常影響Amazon.cn的信譽，不知道現(xiàn)在他們的系統(tǒng)是否已經(jīng)解決這一問題，不過現(xiàn)在《深入理解操作系統(tǒng)》一書的Joyo價已經(jīng)今非昔比了。不知道各位高手是如何解決這一問題的，歡迎大家將自己的成功經(jīng)驗寫在評論中。
回復(fù)：首先說一下數(shù)據(jù)庫服務(wù)器的負擔(dān)，想一下每訪問一個頁面要對數(shù)據(jù)庫進行多少次訪問，然后想一下多次訪問才能換來一次放購物車的操作（訪問次數(shù)主要取決于網(wǎng)站易用性的設(shè)計，這是另外一個話題），所以，雖然在這里修改設(shè)計可以減輕一些數(shù)據(jù)庫壓力，但是這里并不是瓶頸，丁學(xué)認為不需要在這里太在意。
目前比較通用的做法，購物車的商品是不會立即扣減庫存的，主要是為了防止有人通過購物車惡意占用商品，另外一般都會給一個冗余量，因為大部分購物車里的商品不會進入最終的成功訂單，不可以讓購物車影響銷量，這是必須做到的。庫存一般在訂單成功提交的時候扣減庫存，也就是用戶在提交訂單時，你還有一次機會提示用戶沒有庫存了，所以更沒有必須在放到購物車時就扣減庫存。對于“成功訂單”，并不是所有用戶提交的訂單都算成功訂單，這里有一個自動審單的過程，這個程序不好寫，但確實很重要，根據(jù)以前的數(shù)據(jù)分析、用戶行為、用戶信譽等經(jīng)驗性的數(shù)據(jù)來由系統(tǒng)在幾分鐘內(nèi)自動對訂單完成一次審核，審核力度與行業(yè)有關(guān)，這樣可以杜絕大部分的假訂單，其中一部分可能還要由自動審單系統(tǒng)轉(zhuǎn)交人工審核。
這里有一個特殊情況，有一些特殊商品比如演唱會門票，可能會存在在線選座的行為，這種時候放購物車后留座變得比較有用，現(xiàn)在的做法一般是放購物車后立即留座，但某一段時間未成為真實訂單的話就自動釋放，比如十分鐘，雖然無法完全杜絕惡意占座，不過可以解決多數(shù)問題?，F(xiàn)在票務(wù)方面的成功訂單和大部分其他行業(yè)不太一樣，票務(wù)行業(yè)的在線選座成功訂單的判斷標準為是否已經(jīng)成功支付，就是說除非你給錢了，不然只能給你留十分鐘。
問題： 3.訂單和訂單明細同購物車的關(guān)系
我想這個問題可能一直是此類網(wǎng)站的一個大問題吧！前兩天，CSTP的陳老師還曾在電話中面試我這道題，我當(dāng)時很緊張，問題答的不是很清楚。其實這個問題簡單的想并不難：兩個表訂單和明細，訂單表中每列指向明細表中的對應(yīng)列。外鍵就是訂單表中的訂單號。
回復(fù)：這個問題比較簡單，一種是放購物車里就當(dāng)是訂單了，拿一個狀態(tài)標識一下，這種狀態(tài)下訂單是可修改的，購物車合并進訂單系統(tǒng)（注意處理用戶登錄與非登錄狀態(tài)）；第二種是有單獨的購物車表，當(dāng)最終提交訂單時，復(fù)制購物車內(nèi)的信息進訂單和訂單明細表。后一種用得比較多一些，具體選擇哪個取決于行業(yè)和商品屬性。
問題： 4.明細表中訂單號的生成？
這個問題繼承第3個問題，我一直不知道應(yīng)該如何解決此問題。我有兩個解決方案，一個是使用觸發(fā)器，另一個是編程。前者在客戶每次放入購物車中一種商品的同時增加一個明細，確認購買后生成訂單，將明細表中的購買狀態(tài)更改以觸發(fā)觸發(fā)器將生成一個訂單號（當(dāng)然這個訂單號既可以在觸發(fā)器中編程也可以是讓訂單表訂單號的一列設(shè)置為自動生成序號）。后者將判斷訂單號，然后將其加1以生成新的訂單號。但是這兩個方案我總是覺得非常不好，很想知道在商用網(wǎng)站中訂單號是如何處理的。
回復(fù)：首先我個人認為觸發(fā)器的方案不可取，理由不多說，不然又是一大坨。這里也有兩種做法，一種是訂單表自動生成編號，生成訂單時，先寫入訂單表，然后取回訂單號再更新訂單明細表；另一種是按業(yè)務(wù)規(guī)則生成訂單號，當(dāng)訂單號已知后隨便先生成訂單記錄還是明細記錄都可以，但是要保證明細記錄最終一定有訂單記錄，不然會有很多詭異的明細項。后一種辦法又有兩種做法，一是訂單號由數(shù)據(jù)庫生成，一般采用臨時表，好處是可以全業(yè)務(wù)通用流水號，另一種是訂單號由程序生成，程序生成時可以使用GUID，但更好的辦法是使用訂單時間加標識值，時間部分可以根據(jù)訂單量來確定粒度大小，標識部分采用有序編號，時間粒度還要考慮防止別人大概統(tǒng)計你的業(yè)務(wù)量（汗~~~這個也是另外的問題，很多做法，看情況了，改天有空再寫個有關(guān)訂單號生成的文章吧，先回復(fù)這么多，大概信息也夠了……）

標簽：通遼雅安普洱荊門通化運城鷹潭巴彥淖爾

巨人網(wǎng)絡(luò)通訊聲明：本文標題《一些關(guān)于asp 購物車的想法》，本文關(guān)鍵詞一些,關(guān)于,asp,購物車,的,；如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題，煩請?zhí)峁┫嚓P(guān)信息告之我們，我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò)，涉及言論、版權(quán)與本站無關(guān)。

濮阳杆衣贸易有限公司

一些關(guān)于asp 購物車的想法