本章適合初級工程師及中級工程師細看,大佬請隨意
業務上來看,不管是多表查仍是單表存都是合理的,列出如下在購物車上的相關部分業務php
以技術角度說明sql
多表的降價提醒須要第三張表支撐 <商品修改記錄表>segmentfault
這時購物車內的商品與商品表存在關聯,檢測降價的系統就須要在商家修改價格時將檢測結果後查詢加入本商品的購物車,順便去查詢商家修改前價格,算出差價,發送到隊列或者其餘的手段,用戶接收到降價通知,刺激消費。這時你發現,這貌似沒有什麼地方有問題,若是這時候須要增長一個業務,按照用戶加入購物車的時間,提示他在加入購物車後這段時間降價多少?這時是否須要在來個加入購物車的記錄表,這樣不斷的多級關聯,看似沒有問題,實際將業務耦合,一次sql要關聯N個表,若是這時增長sku和spu那就更不用說了。在將來量級上升後是支撐不住的,而且也不方便擴展。服務器
[個人設計並非最好的,僅此參考] , 在考慮到將來業務不斷增長的問題,我是將價格與標題和商品的SKU加入到購物車表內,在商戶修改時無需關心其餘表,直接檢索與修改商品相關的購物車,拿出價格,計算差價,提示用戶。若是計算加入購物車這段實際降價多少,這其實與上述操做同樣,對於單表的設計上,這2種需求實爲一種解決方案。在查詢上也是一條sql語句的實現。架構
固然,咱們仍是須要關聯上,不知道將來的某一天就用的上了呢?
有不少場景,都要將標題呀,內容呀直接存儲,相似與收藏的店鋪和商品,不管賣家怎麼作,用戶購物車,訂單不能動,這是基準。
商品下架,用戶的購物車實際是不能動的,某貓的作法是使其變灰,讓用戶自行刪除。
商家分不少種,商品的標題,圖片或者分類修改了,都屬於下架,這時的多表關聯查詢就不折不扣的失效了。
其實商品的下架應該直接通知購物車下架 (變灰),並不是關聯查詢是否下架。若是你非要這樣作,那你依舊須要作一些表去記錄。性能
我並非說不須要作記錄。而是記錄的表實際是不參與業務查詢的。編碼
邏輯這裏特指代碼的架構編寫。以php爲例,能夠參考我以前的文章 https://segmentfault.com/a/11...
在邏輯方面,要考慮方面比較多,相似sql的性能,代碼的性能,服務器的性能等。儘可能避免多表查詢吧。spa
百度百科的定義是設計
可複用性(Reuseability)複用又叫重用,是重複使用的意思。目前,通常軟件的複用率並不高,尤爲在國內。複用的好處能夠獲得 較高的生產效率以及隨之而來的成本下降、較高的軟件質量(錯誤能夠更快的被糾正)以及 恰當的使用複用能夠改善系統的可維護性。
在購物車的設計上,重用主要提如今商品信息的存儲方式上,避免屢次去聯表查詢,在業務量大後的份表分庫提現會更明顯。blog
百度百科的定義是:
設計良好的代碼容許更多的功能在必要時能夠被插入到適當的位置中。這樣作的目的的是爲了應對將來可能須要進行的修改,而形成代碼被過分工程化地開發。
正常購物車、商品、優惠券都是獨立的系統及功能,不要看作商品在購物車內。現實和邏輯並不是是一脈相承的。就假設在實際生活中,物品僅僅是放在購物車中,若是不結帳,依舊不屬於本身。爲了方便擴展更多業務,儘可能在設計之初,功能與功能之間不要「粘」在一塊兒。
百度百科的定義是:
系統的可維護性是衡量一個系統的可修復(恢復)性和可改進性的難易程度。所謂可修復性是指在系統發生故障後可以排除(或抑制)故障予以修復,並返回到原來正常運行狀態的可能性。而可改進性則是系統具備接受對現有功能的改進,增長新功能的可能性。
購物車的設計之初也是考慮將來商品的業務功能各類變動。不如簡單點,直接將其屬性存到購物車。
初期的設計,決定將來開發及重構的複雜度。功能與功能,系統與系統之間儘可能避免直接關聯。
後期的數據統計、計算也會受到前期設計的影響。
感謝大家看到這裏,下一篇我會講一下關於電商系統的商品設計的部分。有什麼問題能夠評論區提問。謝謝