首先先感谢一下DCE。让我百般周折

现开发一套类似电商的系统，有关数据库方面是我全权负责。其中有关活动和优惠券方面真是让我煞费苦心

业务逻辑是：

1.userstory：首先用户希望全局5个模块—洗车洗衣洗车商城洗衣商城和咖啡厅，

2.userstory：用户希望各个模块分开，每个模块商品单独存放！

3.userstory：客户希望不需要配置多个活动。实现一个活动下配置多个小活动。且模块可多选，商品可多选

3.usercase：

4.userstory：用户希望分为四种活动，分别是满减买赠折扣定额

5.userstory：用户希望优惠卷同上，大概差不多

通过以上userstory可以大概了解整体逻辑。不大概反正也差不多这样

活动表结构实现方法。活动表（主表）、活动系表（存放范围）、买赠商品表（存放买的商品）、买赠商品关系表（存放买多                                            少送多少的关系）

不要问我为什么这么设计。首先为什么活动分主系表。因为模块和活动是多对1.其次为何对买赠单独存放。因为买商品和赠商品是多对多。

eg1：买a赠b       买a赠c      买a赠d           

eg2；买a赠b     买a赠c     买b赠d

eg3：买ab赠c       买a赠d  

如上例子是需要在一个活动中配置。所以迫不得已进行表结构拆分

后来发现判断不下去了。是在太多了

所以第一次对表进行完善

取消适用项目处的多选-----修改方法

对商品进行套餐化。也就是说把ac看作是一个商品进行处理。适用于所有模块。这样删除后面使用项目处多选

具体实行方法（表结构变动）：商品表进行拆分。加入商品和货品两个概念-----商品为货品的组合。并且商品有价格有数量。货品实际上时不存在价格的。创建货品时自动创建一个数量为1的此商品。会保证前台显示逻辑不发生冲突。人为的加入套餐的概念。

针对于貌似全场打8折和新品打8折。不采用人为多选配置。对商品加入分组概念（tag）一个商品可以有多个tag。暂时为逗号拼接。在加入是否为全场的概念

何为是否为全场的概念呢？因为在配置活动时会有如下两个概念混淆不清

1.配置商品中所有订单中商品相加满足规定价格则打折

eg：满100-20 商品a-20-买3个   商品b-50-买1个    这时如果选择全场打折也就是意味着计算方法是20*3+50*1    判定为满足

2.配置商品为单独打折

eg：满100-20    商品a-20-买3个   商品b-50-买2个        这时就是分别判断各个商品是否满足。满足哪个打折哪个。

针对于买赠还有一点特殊处理，就是在代码中认为判断买的商品是否一样。如果一样则买商品中存储1个买的商品。赠品关系表则会对应两个关系。下图为示例代码：

 

实现判断商品。取出重复。加入关系表

当然此处买赠商品表中商品时跟随活动的。每个活动就算商品相同。也为两条数据。换句话说适用商品主键和活动主键作为联合主键

至于适用模块处，加入套餐选项即可改成单选

多行逻辑变为多个小活动。同时满足同时打折。但是打折类型不会是多个。一个活动只能有一种活动方式

暂时先只发现这么多便捷方法。 

当然折一切的一切都是因为活动时跟随商品二并不是跟随订单

eg；买了abc   其中ab参加活动    就为ab打折     如果其中a参加活动则为a打折。换句话说就是满足哪个打折哪个。

现在大多数活动都是跟随订单。比如饿了么。有一个不参加满减则此订单不参加满减。

 

如果后期发现其他特殊之处会继续补充！！！

最后再次感谢

DCE

 

 

——————————————————————————————————

作者：Henny_CHN

转载请标明出处，原文地址：  

https://blog.****.net/a1234012340a/article/details/89484028

如果感觉本文对您有帮助，请留下您的赞，您的支持是我坚持写作最大的动力，谢谢！