本章适合初级工程师及中级工程师细看,大佬请随意
业务上来看,不管是多表查仍是单表存都是合理的,列出如下在购物车上的相关部分业务php
以技术角度说明sql
多表的降价提醒须要第三张表支撑 <商品修改记录表>segmentfault
这时购物车内的商品与商品表存在关联,检测降价的系统就须要在商家修改价格时将检测结果后查询加入本商品的购物车,顺便去查询商家修改前价格,算出差价,发送到队列或者其余的手段,用户接收到降价通知,刺激消费。这时你发现,这貌似没有什么地方有问题,若是这时候须要增长一个业务,按照用户加入购物车的时间,提示他在加入购物车后这段时间降价多少?这时是否须要在来个加入购物车的记录表,这样不断的多级关联,看似没有问题,实际将业务耦合,一次sql要关联N个表,若是这时增长sku和spu那就更不用说了。在将来量级上升后是支撑不住的,而且也不方便扩展。服务器
[个人设计并非最好的,仅此参考] , 在考虑到将来业务不断增长的问题,我是将价格与标题和商品的SKU加入到购物车表内,在商户修改时无需关心其余表,直接检索与修改商品相关的购物车,拿出价格,计算差价,提示用户。若是计算加入购物车这段实际降价多少,这其实与上述操做同样,对于单表的设计上,这2种需求实为一种解决方案。在查询上也是一条sql语句的实现。架构
固然,咱们仍是须要关联上,不知道将来的某一天就用的上了呢?
有不少场景,都要将标题呀,内容呀直接存储,相似与收藏的店铺和商品,不管卖家怎么作,用户购物车,订单不能动,这是基准。
商品下架,用户的购物车实际是不能动的,某猫的作法是使其变灰,让用户自行删除。
商家分不少种,商品的标题,图片或者分类修改了,都属于下架,这时的多表关联查询就不折不扣的失效了。
其实商品的下架应该直接通知购物车下架 (变灰),并不是关联查询是否下架。若是你非要这样作,那你依旧须要作一些表去记录。性能
我并非说不须要作记录。而是记录的表实际是不参与业务查询的。编码
逻辑这里特指代码的架构编写。以php为例,能够参考我以前的文章 https://segmentfault.com/a/11...
在逻辑方面,要考虑方面比较多,相似sql的性能,代码的性能,服务器的性能等。尽可能避免多表查询吧。spa
百度百科的定义是设计
可复用性(Reuseability)复用又叫重用,是重复使用的意思。目前,通常软件的复用率并不高,尤为在国内。复用的好处能够获得 较高的生产效率以及随之而来的成本下降、较高的软件质量(错误能够更快的被纠正)以及 恰当的使用复用能够改善系统的可维护性。
在购物车的设计上,重用主要提如今商品信息的存储方式上,避免屡次去联表查询,在业务量大后的份表分库提现会更明显。blog
百度百科的定义是:
设计良好的代码容许更多的功能在必要时能够被插入到适当的位置中。这样作的目的的是为了应对将来可能须要进行的修改,而形成代码被过分工程化地开发。
正常购物车、商品、优惠券都是独立的系统及功能,不要看作商品在购物车内。现实和逻辑并不是是一脉相承的。就假设在实际生活中,物品仅仅是放在购物车中,若是不结帐,依旧不属于本身。为了方便扩展更多业务,尽可能在设计之初,功能与功能之间不要“粘”在一块儿。
百度百科的定义是:
系统的可维护性是衡量一个系统的可修复(恢复)性和可改进性的难易程度。所谓可修复性是指在系统发生故障后可以排除(或抑制)故障予以修复,并返回到原来正常运行状态的可能性。而可改进性则是系统具备接受对现有功能的改进,增长新功能的可能性。
购物车的设计之初也是考虑将来商品的业务功能各类变动。不如简单点,直接将其属性存到购物车。
初期的设计,决定将来开发及重构的复杂度。功能与功能,系统与系统之间尽可能避免直接关联。
后期的数据统计、计算也会受到前期设计的影响。
感谢大家看到这里,下一篇我会讲一下关于电商系统的商品设计的部分。有什么问题能够评论区提问。谢谢