本人沒有做過什麼真題，因為是個學生也沒有機會實習，因此一直做著學校的模擬題目。
今天又要重新完善一下圖書銷售系統了，當開始想購物車這個模組的時候，我的疑惑接踵而來。
1.購物車中的資料是否應該儲存在資料庫中？
我特別想知道在真正的專案中，那些真正的軟體工程師是如何考慮這個問題的。在google上一搜，搜到了一篇咱園子裡一位網友的觀點：購物車應該是個臨時儲存資料的模組，他將其存放在session物件中。這位網友說的很有道理，不過我並不喜歡這樣的做法。如果大家都將其儲存在session物件中，成千上萬個使用者一同購物的話，想必asp.net伺服器必將承受巨大的負載。也許像我們國內的**可能會好一些，但想amazon這樣的**，怎麼做的呢？amazon中國**，也就是joyo的**，並不是將其儲存在session物件中，因為我如果這次放入購物車中的商品沒有提交訂單，下次登入後購物車中還會有這些商品。因此，我想他們可能是將這些購物車中的資料放入了資料庫中。
2.關於併發？
3.訂單和訂單明細同購物車的關係
我想這個問題可能一直是此類**的乙個大問題吧！前兩天，cstp的陳老師還曾在**中面試我這道題，我當時很緊張，問題答的不是很清楚。其實這個問題簡單的想並不難：兩個表訂單和明細，訂單表中每列指向明細表中的對應列。外來鍵就是訂單表中的訂單號。
4.明細表中訂單號的生成？
這個問題繼承第3個問題，我一直不知道應該如何解決此問題。我有兩個解決方案，乙個是使用觸發器，另乙個是程式設計。前者在客戶每次放入購物車中一種商品的同時增加乙個明細，確認購買後生成訂單，將明細表中的購買狀態更改以觸發觸發器將生成乙個訂單號（當然這個訂單號既可以在觸發器中程式設計也可以是讓訂單表訂單號的一列設定為自動生成序號）。後者將判斷訂單號，然後將其加1以生成新的訂單號。但是這兩個方案我總是覺得非常不好，很想知道在商用**中訂單號是如何處理的。
看看上面，都成了問題集了，呵呵。
問題：1.購物車中的資料是否應該儲存在資料庫中？
我特別想知道在真正的專案中，那些真正的軟體工程師是如何考慮這個問題的。在google上一搜，搜到了一篇咱園子裡一位網友的觀點：購物車應該是個臨時儲存資料的模組，他將其存放在session物件中。這位網友說的很有道理，不過我並不喜歡這樣的做法。如果大家都將其儲存在session物件中，成千上萬個使用者一同購物的話，想必asp.net伺服器必將承受巨大的負載。也許像我們國內的**可能會好一些，但想amazon這樣的**，怎麼做的呢？amazon中國**，也就是joyo的**，並不是將其儲存在session物件中，因為我如果這次放入購物車中的商品沒有提交訂單，下次登入後購物車中還會有這些商品。因此，我想他們可能是將這些購物車中的資料放入了資料庫中。
回覆：首先說一下資料庫伺服器的負擔，想一下每訪問乙個頁面要對資料庫進行多少次訪問，然後想一下多次訪問才能換來一次放購物車的操作（訪問次數主要取決於**易用性的設計，這是另外乙個話題），所以，雖然在這裡修改設計可以減輕一些資料庫壓力，但是這裡並不是瓶頸，丁學認為不需要在這裡太在意。
目前比較通用的做法，購物車的商品是不會立即扣減庫存的，主要是為了防止有人通過購物車惡意占用商品，另外一般都會給乙個冗餘量，因為大部分購物車裡的商品不會進入最終的成功訂單，不可以讓購物車影響銷量，這是必須做到的。庫存一般在訂單成功提交的時候扣減庫存，也就是使用者在提交訂單時，你還有一次機會提示使用者沒有庫存了，所以更沒有必須在放到購物車時就扣減庫存。對於「成功訂單」，並不是所有使用者提交的訂單都算成功訂單，這裡有乙個自動審單的過程，這個程式不好寫，但確實很重要，根據以前的資料分析、使用者行為、使用者信譽等經驗性的資料來由系統在幾分鐘內自動對訂單完成一次審核，審核力度與行業有關，這樣可以杜絕大部分的假訂單，其中一部分可能還要由自動審單系統轉交人工審核。
問題：3.訂單和訂單明細同購物車的關係
我想這個問題可能一直是此類**的乙個大問題吧！前兩天，cstp的陳老師還曾在**中面試我這道題，我當時很緊張，問題答的不是很清楚。其實這個問題簡單的想並不難：兩個表訂單和明細，訂單表中每列指向明細表中的對應列。外來鍵就是訂單表中的訂單號。
回覆：這個問題比較簡單，一種是放購物車裡就當是訂單了，拿乙個狀態標識一下，這種狀態下訂單是可修改的，購物車合併進訂單系統（注意處理使用者登入與非登入狀態）；第二種是有單獨的購物車表，當最終提交訂單時，複製購物車內的資訊進訂單和訂單明細表。後一種用得比較多一些，具體選擇哪個取決於行業和商品屬性。
問題：4.明細表中訂單號的生成？
這個問題繼承第3個問題，我一直不知道應該如何解決此問題。我有兩個解決方案，乙個是使用觸發器，另乙個是程式設計。前者在客戶每次放入購物車中一種商品的同時增加乙個明細，確認購買後生成訂單，將明細表中的購買狀態更改以觸發觸發器將生成乙個訂單號（當然這個訂單號既可以在觸發器中程式設計也可以是讓訂單表訂單號的一列設定為自動生成序號）。後者將判斷訂單號，然後將其加1以生成新的訂單號。但是這兩個方案我總是覺得非常不好，很想知道在商用**中訂單號是如何處理的。
回覆：首先我個人認為觸發器的方案不可取，理由不多說，不然又是一大坨。這裡也有兩種做法，一種是訂單表自動生成編號，生成訂單時，先寫入訂單表，然後取回訂單號再更新訂單明細表；另一種是按業務規則生成訂單號，當訂單號已知後隨便先生成訂單記錄還是明細記錄都可以，但是要保證明細記錄最終一定有訂單記錄，不然會有很多詭異的明細項。後一種辦法又有兩種做法，一是訂單號由資料庫生成，一般採用臨時表，好處是可以全業務通用流水號，另一種是訂單號由程式生成，程式生成時可以使用guid，但更好的辦法是使用訂單時間加標識值，時間部分可以根據訂單量來確定粒度大小，標識部分採用有序編號，時間粒度還要考慮防止別人大概統計你的業務量（汗~~~這個也是另外的問題，很多做法，看情況了，改天有空再寫個有關訂單號生成的文章吧，先回覆這麼多，大概資訊也夠了……）
購物車（註冊 登入 購物 購物車 結帳）
購物車 註冊 登入 購物 購物車 結帳 shopping car dict dict money 0 def input username pwd username input username pwd input pwd return username,pwd def goods get with...
購物車原理
1.cookie n cookie儲存在客戶端，且占用很少的資源，瀏覽器允許存放300個cookie，每個cookie的大小為4kb，足以滿足購物車的要求，同時也減輕了伺服器的負荷 n cookie為瀏覽器所內建，使用方便。即使使用者不小心關閉了瀏覽器視窗，只要在cookie定義的有效期內，購物車中...
購物車動畫
金幣終點的x位置 cgfloat positionx 290.0f 終點x 金幣終點的y位置 cgfloat positiony 500.0f 終點y cgmutablepathref path cgpathcreatemutable 金幣的起始x位置 int fromx 20 arc4random...