* 問 [不存價格字段不行嗎？直接查詢商品表獲取價格] * 答 [如果價格更新，應提示用戶，商品的浮動信息。可以選擇直接更新購物車，或者單獨建立一個表，來記錄更新的價格和信息，類似京東] * 問 [聯表查詢可以從商品表中知道商品是否上架] * 答 [商品不存在了如何聯，只會將邏輯整復雜，未來包括降價提醒，無貨提醒，下架提醒，購物車該如何查詢就成了一個問題] * * * # 業務 業務上來看，無論是多表查還是單表存都是合理的，列出以下在購物車上的相關部分業務 – 庫存不足提醒 （提高付款概率） – 降價提醒 （提高付款概率） – 商品下架提醒 – 有關商品的商品優惠券或其他活動 （提高付款概率） ## 降價提醒 多表的降價提醒需要第三張表支撐 ### 多表 這時購物車內的商品與商品表存在關聯，檢測降價的系統就需要在商家修改價格時將檢測結果后查詢加入本商品的購物車，順便去查詢商家修改前價格，算出差價，發送到隊列或者其他的手段，用戶接收到降價通知，刺激消費。這時你發現，這貌似沒有什么地方有問題，如果這時候需要增加一個業務，按照用戶加入購物車的時間，提示他在加入購物車后這段時間降價多少？這時是否需要在來個加入購物車的記錄表，這樣不斷的多級關聯，看似沒有問題，實際將業務耦合，一次sql要關聯N個表，如果這時增加sku和spu那就更不用說了。在未來量級上升后是支撐不住的，并且也不方便擴展。 ### 單表 [我的設計并不是最好的，僅此參考] , 在考慮到未來業務不斷增加的問題，我是將價格與標題和商品的SKU加入到購物車表內，在商戶修改時無需關心其他表，直接檢索與修改商品相關的購物車，拿出價格，計算差價，提示用戶。如果計算加入購物車這段實際降價多少，這其實與上述操作一樣，對于單表的設計上，這2種需求實為一種解決方案。在查詢上也是一條sql語句的實現。 > 當然，我們還是需要關聯上，不知道未來的某一天就用的上了呢？ 有很多場景，都要將標題呀，內容呀直接存儲，類似與收藏的店鋪和商品，無論賣家怎么做，用戶購物車，訂單不能動，這是基準。 ## 商品下架 商品下架，用戶的購物車實際是不能動的，某貓的做法是使其變灰，讓用戶自行刪除。 商家分很多種，商品的標題，圖片或者分類修改了，都屬于下架，這時的多表關聯查詢就徹徹底底的失效了。 其實商品的下架應該直接通知購物車下架 (變灰)，并非關聯查詢是否下架。如果你非要這樣做，那你依舊需要做一些表去記錄。 我并不是說不需要做記錄。而是記錄的表實際是不參與業務查詢的。 # 邏輯 邏輯這里特指代碼的架構編寫。以php為例，要考慮方面比較多，類似sql的性能，代碼的性能，服務器的性能等。盡量避免多表查詢吧。 ## 可復用性 百度百科的定義是 > 可復用性（Reuseability）復用又叫重用，是重復使用的意思。目前，一般軟件的復用率并不高，尤其在國內。復用的好處可以得到 較高的生產效率以及隨之而來的成本降低、較高的軟件質量（錯誤可以更快的被糾正）以及 恰當的使用復用可以改善系統的可維護性。 在購物車的設計上，重用主要提現在商品信息的存儲方式上，避免多次去聯表查詢，在業務量大后的分表分庫提現會更明顯。 ## 可擴展性 百度百科的定義是： > 設計良好的代碼允許更多的功能在必要時可以被插入到適當的位置中。這樣做的目的的是為了應對未來可能需要進行的修改，而造成代碼被過度工程化地開發。 正常購物車、商品、優惠券都是獨立的系統及功能，不要看做商品在購物車內。現實和邏輯并非是一脈相承的。就假設在實際生活中，物品僅僅是放在購物車中，如果不結賬，依舊不屬于自己。為了方便擴展更多業務，盡量在設計之初，功能與功能之間不要“粘”在一起。 ## 可維護性 百度百科的定義是： > 系統的可維護性是衡量一個系統的可修復(恢復)性和可改進性的難易程度。所謂可修復性是指在系統發生故障后能夠排除(或抑制)故障予以修復，并返回到原來正常運行狀態的可能性。而可改進性則是系統具有接受對現有功能的改進，增加新功能的可能性。 購物車的設計之初也是考慮未來商品的業務功能各種變更。不如簡單點，直接將其屬性存到購物車。 # 復雜度 初期的設計，決定未來開發及重構的復雜度。功能與功能，系統與系統之間盡量避免直接關聯。 # 統計 后期的數據統計、計算也會受到前期設計的影響。