谈一谈商城活动设计

如题：浅谈商城活动设计

标题改为“浅谈商城活动的数据库设计”可能更加合理。

文章背景

为何要吐槽，为何要写这篇文章

原本我在弄大数据搜索，本身玩的不亦说乎，虽然感受数据库设计不合理，但我能够数据清洗，弄到本身的搜索引擎里，本身随便玩，因此当时感受在烂的数据库设计和我关系不大，只要我把数据清洗好，弄到本身的引擎里个人搜索正常，准确，问题不大。但突然有一天老大跑来讲ERP对接须要你来lead一下，而后一两个月带着捣乱的产品妹妹，和没有经验开发弟弟搞了ERP的简单对接，而后老大又说我们商城库存总有超卖，想办法设计搞一下，而后就是一入侯门深似海，跳进火坑出不来。原来咱们的商城是这样的一个商城，商城底层设计开发成型有了将近一年时间，我从半路接手，商城要运行，重构要继续。我大概用了一个多月的时间对接了ERP，用了两个多月的时间重构了建立订单和生成订单的功能，而后又用了两个多月的时间完成咱们的会员功能的订单从新计算。大概半年的时间，我已经到了心力憔悴，看代码，开会都头疼的地步，因此实在是忍不住了。

为何要发到网上

想吐糟，可是最近在练习控制情绪，因此用近乎平和的语气控制本身的愤怒情绪，写下这篇商城活动数据库设计，供全部人吐槽，你们吐槽，才是真的吐槽。

原本是想发公司内部员工全部研发参考讨论的，但实在担忧引发公愤，并且由于反应设计问题，数据库问题被领导批评屡次，并且往往不欢而散，因此也不想在跟领导反应了，发到网上跟全部的领导反应吧。（能够说是某某公司的内部资料哦）~其实和某某公司也没有卵关系，你们全部的商城不是或者不该该是都是这样设计更合理么。

扯淡完毕。

文章正文

首先我在这里明确一点，这里我要说的活动设计不是指商城怎么设计活动能最吸引客户吸引用户，能引来更多流量，能帮助商城卖出更可能是商品或打响更高的知名度。
这里我要说的商城活动设计是指在程序开发过程当中，数据库的设计，怎么设计数据表结构，怎么存储，怎么展现，怎么使用。
首先大概了解一下咱们商城的活动，咱们商城的活动有4类，分别是：
一、满赠换购，意思就是购买满了M元以后加N元能够领一个小礼品，这种活动和超市里的那种活动如出一辙，咱们认为N元换购的这个小礼品单价价为N元。
二、满M元减N元，意思就是满了M元以后立减N元，这种活动应该算是超市活动或其余电商购物活动满多少元送券，同样的，只是咱们直接减钱了。在具体的程序计算中，咱们不能算M元减N元就完事了，咱们须要具体到每件商品减小了N’元。活动能够这样设置，程序也能够这样展现，可是计算是不能单纯用文字或者口述来计算的。
三、满M件减N元，意思就是某种商品或者商品组合满了M件以后直接减小N元，这种活动和那种打包一块儿卖的活动很相似。一样和2同样须要精确的计算，要算到具体的每件商品减小了N’元。
四、M钱N件，意思就是打包给M块钱，直接拿走N件商品。这种活动和超市里那种甩卖同样，但程序计算时一样须要精确计算，要算到每件商品N’元。
在如今众多的多的APP中除了咱们商城的这些活动以外，如今不少商城还有各类各样的活动，例如：
五、在买商品买以前能够领券，而后用券直接抵钱购买，券和钱一块儿使用，满多少元能够用券，和我们的优惠券如出一辙
六、还有是能够用钱买券，而后用直接券购买。好比，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,多是参加活动时商品的图片也和通常的不同，会更有吸引力。

以上是我对商品，商城活动设计的一些思路和想法，并非正式的代码，而要转换成代码要思考和设计的更多，更详细。
除了活动的设计，还有我们仓库的设计，按照这个思路你们能够想一想仓库的设计好比包邮规则，拆包规则，等等。

说这些东西是但愿对你们对比如今数据库的设计进行反思和思考。

如今有些东西正在重构，我知道底层数据库表的改动和变化对程序的变更有多大，会对你们形成多大的工做量和影响，也知道每次发版咱们的时间有多紧张，可是最最但愿看到的重构是全新的设计。

你们想一想经过这样的设计，这样的思路是否是更加清晰，明朗，经过这种方式的改进，程序是否是能够更加优雅和优化。
这种方式还能够更加有效的使用缓存，内存，规则引擎等一些高级的东西。

 

这样写来，心情会好一些，之后在有实在忍不住的想法，在陆续更新出来。

欢迎你们吐槽~