首先先感谢一下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.csdn.net/a1234012340a/article/details/89484028
如果感觉本文对您有帮助，请留下您的赞，您的支持是我坚持写作最大的动力，谢谢！