如题：浅谈商城活动设计
标题改成“浅谈商城活动的数据库设计”可能更加合理。
文章背景
为什么要吐槽，为什么要写这篇文章
本来我在弄大数据搜索，自己玩的不亦说乎，虽然感觉数据库设计不合理，但我可以数据清洗，弄到自己的搜索引擎里，自己随便玩，所以当时感觉在烂的数据库设计和我关系不大，只要我把数据清洗好，弄到自己的引擎里我的搜索正常，准确，问题不大。但忽然有一天老大跑来说ERP对接需要你来lead一下，然后一两个月带着捣乱的产品妹妹，和没有经验开发弟弟搞了ERP的简单对接，然后老大又说咱们商城库存总有超卖，想办法设计搞一下，然后就是一入侯门深似海，跳进火坑出不来。原来我们的商城是这样的一个商城，商城底层设计开发成型有了将近一年时间，我从半路接手，商城要运行，重构要继续。我大概用了一个多月的时间对接了ERP，用了两个多月的时间重构了创建订单和生成订单的功能，然后又用了两个多月的时间完成我们的会员功能的订单重新计算。大概半年的时间，我已经到了心力憔悴，看代码，开会都头疼的地步，所以实在是忍不住了。
为什么要发到网上
想吐糟，但是最近在练习控制情绪，所以用近乎平和的语气控制自己的愤怒情绪，写下这篇商城活动数据库设计，供所有人吐槽，大家吐槽，才是真的吐槽。
本来是想发公司内部员工所有研发参考讨论的，但实在担心引起公愤，而且因为反应设计问题，数据库问题被领导批评多次，而且每每不欢而散，所以也不想在跟领导反应了，发到网上跟所有的领导反应吧。（可以说是某某公司的内部资料哦）~其实和某某公司也没有卵关系，大家所有的商城不是或者不应该是都是这样设计更合理么。
扯淡完毕。
文章正文
首先我在这里明确一点，这里我要说的活动设计不是指商城怎么设计活动能最吸引客户吸引用户，能引来更多流量，能帮助商城卖出更多是商品或打响更高的知名度。
这里我要说的商城活动设计是指在程序开发过程中，数据库的设计，怎么设计数据表结构，怎么存储，怎么展示，怎么使用。
首先大概了解一下我们商城的活动，我们商城的活动有4类，分别是：
1、满赠换购，意思就是购买满了M元之后加N元可以领一个小礼品，这种活动和超市里的那种活动一模一样，我们认为N元换购的这个小礼品单价价为N元。
2、满M元减N元，意思就是满了M元之后立减N元，这种活动应该算是超市活动或其他电商购物活动满多少元送券，一样的，只是我们直接减钱了。在具体的程序计算中，我们不能算M元减N元就完事了，我们需要具体到每件商品减少了N’元。活动可以这样设置，程序也可以这样展示，但是计算是不能单纯用文字或者口述来计算的。
3、满M件减N元，意思就是某种商品或者商品组合满了M件之后直接减少N元，这种活动和那种打包一起卖的活动很类似。同样和2一样需要精确的计算，要算到具体的每件商品减少了N’元。
4、M钱N件，意思就是打包给M块钱，直接拿走N件商品。这种活动和超市里那种甩卖一样，但程序计算时同样需要精确计算，要算到每件商品N’元。
在现在众多的多的APP中除了我们商城的这些活动之外，现在很多商城还有各种各样的活动，例如：
5、在买商品买之前可以领券，然后用券直接抵钱购买，券和钱一起使用，满多少元可以用券，和咱们的优惠券一模一样
6、还有是可以用钱买券，然后用直接券购买。比如，30元买个50元的券，然后用50元的券买商品。
这些活动都是有区别的，各有各的优点和不足，我们不做讨论，除了这些活动，还有其他活动，
如：限时抢购活动，团购活动，等等这些都是活动。
那么如何把活动进行抽象，进行合理的数据库设计。这是值得认真思考的一个问题。
首先第一，
活动有本身的些属性，比如上边说的那4~6，8种活动中，要提取公共的属性，比如活动的名字，时间，和其他的一些基本的属性这里不多赘述，这些属性都很简单，做过数据库设计的人一般都能想到，那么除了这些属性，所有这些活动的本质是什么。
换购，满减，M元M件，限时抢购，团购，还有那些共同点。
规则！对！我们把这些活动的核心的东西提取处出来通成为规则。
这样应该就可以看到一个更加清晰和合理和逻辑更强的设计。
就是活动下有很多规则，或者说活动是一些规则的组合，换句话说活动就是一组规则。
那么要怎么设计，通过上边的分析和提取，大概的设计就有可初步的端倪，
活动主表有自己的属性，一个活动有很多规则，规则子表。
大概的设计至少应该是这样
Activity(
int id pk,
string name,
timestamp start_time,
timestamp end_time,
timestamp create_time
)
ActivityRule(
int id pk,
int activity_id,
XXXXXX type
XXXXXX condition
XXXXXX result
)
ActivityTags(
int id pk,
int activity_id,
string name
)
从上边的结构可以这样理解，我们创建一个活动，活动下边有一个或多个规则，活动还有一堆标签。
举个简单例子，我们创建一个满M元减少N元的多动，比如：悦诗风吟618大促，满199减少30，满299减少50，
那么对应的数据存储就是：
活动表： 618大促活动
活动规则表：
规则1：满299减少50，对应的存储结构可能是：condition >=299，result -50
规则2：满199减少30，对应的存储结构可能是：condition >=199，result -30
大概就是这个样子，具体的存储结构可以更加具体的详细的在讨论。
再比如限时抢购，那么它的condition就是什么，result是什么，
在比如团购，那么它的condition就是什么，result是什么，
最后，最后，最后一个问题，活动的商品和活动怎么关联，怎么知道哪些商品参加了那个活动，活动的商品，怎么存，怎么关联。
这个问题，我本来想关联力度越小越好，想关联到ActivityRule上，但是回头想想关联在Activity上可能也是一个非常棒的选择。
大概会是这个样子
ActivityGoods(
int id pk,
int activity_id,
int goods_id,
numberic goods_prie,
string goods_image
)
这样的一张表大概是定义了活动和商品的关系，也就是说，说明了那些商品参加了什么活动，
商品价格本身可以不用，但是有些特殊的活动或商品或修改商品在活动中的价格，所以把价格也拿过来，可以修改活动中的价格。
关于image,可能是参加活动时商品的图片也和一般的不一样，会更有吸引力。
以上是我对商品，商城活动设计的一些思路和想法，并不是正式的代码，而要转换成代码要思考和设计的更多，更详细。
除了活动的设计，还有咱们仓库的设计，按照这个思路大家可以想想仓库的设计比如包邮规则，拆包规则，等等。
说这些东西是希望对大家对比现在数据库的设计进行反思和思考。
现在有些东西正在重构，我知道底层数据库表的改动和变化对程序的变动有多大，会对大家造成多大的工作量和影响，也知道每次发版我们的时间有多紧张，但是最最希望看到的重构是全新的设计。
大家想想通过这样的设计，这样的思路是不是更加清晰，明朗，通过这种方式的改进，程序是不是可以更加优雅和优化。
这种方式还可以更加有效的使用缓存，内存，规则引擎等一些高级的东西。
这样写来，心情会好一些，以后在有实在忍不住的想法，在陆续更新出来。
欢迎大家吐槽~