资讯专栏INFORMATION COLUMN

电商系统设计之购物车

TigerChain / 1334人阅读

摘要:可扩展性百度百科的定义是设计良好的代码允许更多的功能在必要时可以被插入到适当的位置中。正常购物车商品优惠券都是独立的系统及功能,不要看做商品在购物车内。可维护性百度百科的定义是系统的可维护性是衡量一个系统的可修复恢复性和可改进性的难易程度。

本章适合初级工程师及中级工程师细看,大佬请随意
前言

问 [不存价格字段不行吗?直接查询商品表获取价格]

答 [如果价格更新,应提示用户,商品的浮动信息。可以选择直接更新购物车,或者多带带建立一个表,来记录更新的价格和信息,类似京东]

问 [联表查询可以从商品表中知道商品是否上架]

答 [商品不存在了如何联,只会将逻辑整复杂,未来包括降价提醒,无货提醒,下架提醒,购物车该如何查询就成了一个问题]



上一篇文章在对于购物车业务及数据表设计中,有位童鞋在评论区与我讨论许久,特此独立一篇文章来详解下我的想法及我为什么这么做,以下为在业务层面、逻辑层面、未来功能的可扩展性、编码的复杂度、数据统计层面来解释下我的设计。业务

业务上来看,无论是多表查还是单表存都是合理的,列出以下在购物车上的相关部分业务

库存不足提醒 (提高付款概率)

降价提醒 (提高付款概率)

商品下架提醒

有关商品的商品优惠券或其他活动 (提高付款概率)

以技术角度说明

降价提醒

多表的降价提醒需要第三张表支撑 <商品修改记录表>

多表

这时购物车内的商品与商品表存在关联,检测降价的系统就需要在商家修改价格时将检测结果后查询加入本商品的购物车,顺便去查询商家修改前价格,算出差价,发送到队列或者其他的手段,用户接收到降价通知,刺激消费。这时你发现,这貌似没有什么地方有问题,如果这时候需要增加一个业务,按照用户加入购物车的时间,提示他在加入购物车后这段时间降价多少?这时是否需要在来个加入购物车的记录表,这样不断的多级关联,看似没有问题,实际将业务耦合,一次sql要关联N个表,如果这时增加sku和spu那就更不用说了。在未来量级上升后是支撑不住的,并且也不方便扩展。

单表

[我的设计并不是最好的,仅此参考] , 在考虑到未来业务不断增加的问题,我是将价格与标题和商品的SKU加入到购物车表内,在商户修改时无需关心其他表,直接检索与修改商品相关的购物车,拿出价格,计算差价,提示用户。如果计算加入购物车这段实际降价多少,这其实与上述操作一样,对于单表的设计上,这2种需求实为一种解决方案。在查询上也是一条sql语句的实现。

当然,我们还是需要关联上,不知道未来的某一天就用的上了呢?
有很多场景,都要将标题呀,内容呀直接存储,类似与收藏的店铺和商品,无论卖家怎么做,用户购物车,订单不能动,这是基准。
商品下架

商品下架,用户的购物车实际是不能动的,某猫的做法是使其变灰,让用户自行删除。
商家分很多种,商品的标题,图片或者分类修改了,都属于下架,这时的多表关联查询就彻彻底底的失效了。
其实商品的下架应该直接通知购物车下架 (变灰),并非关联查询是否下架。如果你非要这样做,那你依旧需要做一些表去记录。

我并不是说不需要做记录。而是记录的表实际是不参与业务查询的。

逻辑

逻辑这里特指代码的架构编写。以php为例,可以参考我之前的文章 https://segmentfault.com/a/11...
在逻辑方面,要考虑方面比较多,类似sql的性能,代码的性能,服务器的性能等。尽量避免多表查询吧。

可复用性

百度百科的定义是

可复用性(Reuseability)复用又叫重用,是重复使用的意思。目前,一般软件的复用率并不高,尤其在国内。复用的好处可以得到 较高的生产效率以及随之而来的成本降低、较高的软件质量(错误可以更快的被纠正)以及 恰当的使用复用可以改善系统的可维护性。

在购物车的设计上,重用主要提现在商品信息的存储方式上,避免多次去联表查询,在业务量大后的份表分库提现会更明显。

可扩展性

百度百科的定义是:

设计良好的代码允许更多的功能在必要时可以被插入到适当的位置中。这样做的目的的是为了应对未来可能需要进行的修改,而造成代码被过度工程化地开发。

正常购物车、商品、优惠券都是独立的系统及功能,不要看做商品在购物车内。现实和逻辑并非是一脉相承的。就假设在实际生活中,物品仅仅是放在购物车中,如果不结账,依旧不属于自己。为了方便扩展更多业务,尽量在设计之初,功能与功能之间不要“粘”在一起。

可维护性

百度百科的定义是:

系统的可维护性是衡量一个系统的可修复(恢复)性和可改进性的难易程度。所谓可修复性是指在系统发生故障后能够排除(或抑制)故障予以修复,并返回到原来正常运行状态的可能性。而可改进性则是系统具有接受对现有功能的改进,增加新功能的可能性。

购物车的设计之初也是考虑未来商品的业务功能各种变更。不如简单点,直接将其属性存到购物车。

复杂度

初期的设计,决定未来开发及重构的复杂度。功能与功能,系统与系统之间尽量避免直接关联。

统计

后期的数据统计、计算也会受到前期设计的影响。

致谢

感谢你们看到这里,下一篇我会讲一下关于电商系统的商品设计的部分。有什么问题可以评论区提问。谢谢

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/28867.html

相关文章

  • 电商系统设计商品[番外篇]

    摘要:前言这是电商系统设计系列在商品设计这块的最后一篇文章。电商系统商品相关的文章已经到了尾声如果有其他商品相关的文章需要编写可以私信联系我毕竟我也是公司员工写这些文章并不是我的工作,只是记录我的职业生涯。 showImg(https://segmentfault.com/img/bVbePdh?w=1260&h=628); 前言 这是电商系统设计系列在商品设计这块的最后一篇文章。以下是其他...

    crossoverJie 评论0 收藏0
  • 电商系统设计用户系统

    摘要:致谢感谢你们看到这里,下一篇我会讲一下关于电商系统的商品设计的部分。 showImg(https://segmentfault.com/img/bVbclTs?w=500&h=329); 电商大伙每天都在用,类似某猫,某狗等。电商系统设计看似复杂又很简单,看似简单又很复杂本章适合初级工程师及中级工程师细看,大佬请随意 前言 设计以以下为工具讲起 PHP为开发语言 基于Laravel框...

    lindroid 评论0 收藏0
  • 电商系统设计商品 (下)

    摘要:订单号用户商品标题商品价格商品封面图商品其他属性小明爱疯手机其他属性像上表中设计,有人会问了那关联的意义何在呢我的回答是保持数据关联,虽然商户有可能改变商品属性,但作为一名程序员,应该尽可能的记录用户所有的动作。 showImg(https://segmentfault.com/img/bVbdtuc?w=1824&h=1028); 电商大伙每天都在用,类似某猫,某狗等。电商系统设计看...

    shiguibiao 评论0 收藏0
  • 电商设计手册基础商品信息

    摘要:商品详情接口商品表按索引查询商品信息。接着,我们来看看和定义名称概念解释标准产品单位剥离销售属性的部分,例如小米。 前言 建议使用大屏设备(例如pad/pc),可以更好的浏览本篇文章 今天我们开始「商品系统」的篇章。本文分为如下五大模块: 需求分析 架构设计 Spu和Sku的故事 数据模型设计 接口设计 第一篇我们主要看看一个入门的电商平台(B2C)如何去构建自己的基础商品信息,其...

    aboutU 评论0 收藏0
  • 夏日葵电商:从5大方面谈微信商城怎样提高用户体验度

    摘要:夏日葵电商从大方面谈微信商城怎样提高用户体验度网购对于用户的意义来说就是买到一个自己需要的东西,至于在什么平台上买其实区别不大,在这种情况下提高用户体验度就显得更加重要了。 夏日葵电商:从5大方面谈微信商城怎样提高用户体验度 网购对于用户的意义来说就是买到一个自己需要的东西,至于在什么平台上买其实区别不大,在这种情况下提高用户体验度就显得更加重要了。作为最成功的电商平台之一,淘宝网不断...

    Tecode 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<