本章适合初级工程师和中级工程师仔细阅读。如果您不想保存价格字段，请随时在前言中询问？直接查询商品表获取价格】回答【如果价格有更新，应该提示用户提供商品的浮动信息。可以选择直接更新购物车，也可以单独建一个表记录更新后的价格和信息，类似京东】Q【联表查询可以从商品表知道商品是否上架】答【如何如果产品不存在链接，只会使逻辑复杂化。未来将包括降价提醒、缺货提醒、下架提醒。如何查询购物车成为问题】上一篇文章购物车业务和数据表的设计，有童鞋在评论区和我讨论了很久，这里单独出一篇文章来解释我的想法和我为什么这样做详细说一下，下面是从业务层面、逻辑层面、未来的功能扩展性、编码复杂度、数据统计层面的设计来阐述我的。从业务角度来看，无论是多表查询还是单表存储合理，下面列出购物车相关部分业务库存不足提醒（增加支付概率）降价提醒（增加支付概率)与商品相关的下架提醒商品优惠券或商品的其他活动（增加支付概率）从技术角度解释降价提醒。多表降价提醒需要第三张表支持<商品修改记录表>多表。这时候购物车里的商品就和商品表相关联了，降价检测系统需要在商户修改价格时，查询检测结果并添加到该商品的购物车中。消耗。这时候你发现好像没什么问题了。如果这时候需要添加商家，根据用户添加购物车的时间，提醒用户添加购物车后的这段时间降价多少？这时候是否需要在购物车中添加一个记录表呢？这样一个连续的多层次联想，似乎是没有问题的。事实上，业务是耦合的。一条SQL需要关联N张表。如果这时候加上sku和spu，就更没有必要了。说。以后量级上升后就撑不住了，不方便扩容。单表【我的设计不是最好的，仅供参考】，考虑到以后业务越来越多，我把商品的价格，title，SKU加入到购物车表中，不需要关心商家修改其他表时，直接检索修改商品相关的购物车，取出价格，计算差价，提示用户。如果计算加入购物车期间的实际降价，这个其实和上面的操作是一样的。对于单表的设计，这两个需求其实是一个解决方案。也是查询中一条sql语句的实现。当然，我们仍然需要联系。不知道以后有没有用到呢？很多场景下，title和content必须直接存储，类似于喜欢的店铺和商品。无论卖家怎么做，用户的购物车和订单都无法动弹。这是基准。当商品下架时，用户的购物车实际上并不能移动。某猫的做法是将其置灰，让用户自行删除。商家有很多种。如修改商品名称、图片或分类，将被下架。这时候多表关联查询就彻底失效了。实际上，商品下架时，应该直接通知购物车下架（灰色），而不是相关查询是否下架。如果一定要这样做，那么还是需要做一些表格来记录。我并不是说不需要保留记录。相反，记录的表实际上并不参与业务查询。Logic这里的Logic特指代码架构的写法。以PHP为例，可以参考我之前的文章https://segmentfault.com/a/11...在逻辑上，需要考虑的方面很多，比如类SQL性能，代码性能，服务器性能等。尽量避免多表查询。可重用性百度百科的定义是可重用性（Reuseability）Reuse也叫reuse，意思是重复使用。目前通用软件的复用率不高，尤其是在中国。重用的好处可以是更高的生产率和随之而来的成本降低、更高的软件质量（可以更快地纠正错误），正确使用重用可以提高系统的可维护性。在购物车的设计中，复用主要集中在商品信息的存储方式上，避免对联表进行多次查询，业务量大后表分库的提现会更加明显.百度百科对可扩展性的定义是：设计良好的代码可以让更多的功能在需要的时候插入到合适的位置。这样做的目的是过度设计代码以响应将来可能需要的修改。正常的购物车、商品、优惠券都是独立的系统和功能，不应视为购物车中的商品。现实与逻辑并不齐头并进。假设在现实生活中，物品只是放在购物车里，如果你不结账，它们仍然不属于你。为了方便扩展更多的业务，在设计之初尽量不要把功能“粘”在一起。百度百科对可维护性的定义是：系统的可维护性是衡量一个系统的可修复性（恢复性）和可改进性的难易程度。所谓可修复性，是指系统发生故障后，能够排除（或抑制）故障，修复故障，恢复到原来正常运行状态的可能性。可改进性是指系统具有接受改进现有功能和增加新功能的可能性。购物车在设计之初就考虑了未来商品业务功能的各种变化。不是直接把它的属性保存到购物车那么简单。复杂性初始设计决定了未来开发和重构的复杂性。尽量避免功能与功能、系统与系统的直接关联。统计后期的数据统计和计算也会受到之前设计的影响。谢谢您阅读此篇。在下一篇文章中，我将谈谈电子商务系统的产品设计。大家有什么问题可以在评论区提问。谢谢
