这是一个创建于 2034 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前创建优惠券有三种形式：
1.全部商品可用（这种最简单）。
2.部分商品可用 /（商品分门店商品和网店商品，因此包含 [网店商品全部可用+部分门店商品可用] ， [网店商品部分可用+全部门店商品可用] ， [网店商品部分可用+全部门店部分可用] 这几种组合）。
3.部分商品不可用（商品分门店商品和网店商品，组合同上）。
当前的优惠券设计是一个商家的优惠券主表，存储主要数据，然后另外一个和商品的关联表，主表里会记录券的类型，如果是全部商品可用，那么关联表里就无数据，如果是部分可用 /不可用，那么就会在关联表里记录 id，如果是网店 /门店全部可用，那么会记录一个 id 等于 0 的。
现在的问题是，按照这种设计，在用户进行结算的时候，查询优惠券的步骤非常繁杂，虽然实现是可以实现，但是很麻烦。
因此在做这部分的同事也有提议说要把所有的优惠券可用 /不可用的商品 id 都关联到关联表，即：如果商家 A 添加了一个全部商品可用的优惠券，就将他所有的商品都关联到关联表，部分同理。说这种他就很容易搜索，然而这种会造成巨大的冗余数据，而且每次商家新增商品的时候，都要对所有的优惠券进行筛选，然后新增关联数据，商家多起来，商品多起来，那数据量简直会爆炸，必然要分表，但优惠券本身还有失效过期等情况，后续处理也很麻烦。
想问一下老哥们，对于这种需求，有没有更好一些的设计方法？因为是全新功能，所以没有历史包袱。
 | 1 kop1989 2020 年 9 月 10 日 我们的做法是反过来，商品中记录可用的券类型。 然后券本身记录可用门店以及互斥关系。 |
 | 2 vvmint233 2020 年 9 月 10 日 感觉应该先筛选用户所有能用的优惠券然后根据优惠券的条件做过滤, 如果门店数量有限在捞库的时候根据可用的门店 id 把一些优惠券过滤掉, 再根据券本身的属性过滤掉超过时间的, 这样用户可用的应该不会很多, 剩下的主要就是优惠券的不适用商品, 你得根据商品的属性做优惠券的过滤, 表就一个商品和优惠券的. 我也没做过类似的但感觉这样会比较简单清楚 |
 | 3 owenliang 2020 年 9 月 10 日 我感觉你应该拿着购物车中的商品，去查询关联了哪些卷，这个计算规模是可控的。 如果你想拿着用户手中的优惠券，去查能应用到哪些商品上，这个计算规模不是可控的哦。 |
 | 4 pushback 2020 年 9 月 10 日 优惠券表（选择类型：全部可用、部分可用、部分不可用，分别对应适用商家、适用商品、不适用商品）->优惠券适用商家表、优惠券适用商品表、优惠券不适用商品表->商品表、商家表 查询：根据用户所持优惠券进行过滤->根据下单界面商家 id 进行适用过滤->根据下单界面商品 id 和优惠券类型进行适用、不适用商品进行过滤 更新 1 （商品更新）：添加-不影响适用和不适用表、删除-不影响适用和不适用表（但需要定期处理不必要关系数据） 更新 2 （优惠券更新）：更加优惠券类型去决定影响不同的表 因为我们之前的业务是能对优惠券进行类型切换的，只需要在 SQL 中选择好表范围主体就行，加一些索引都能保持在 0.03s 上下 |
Select Language