基于微信分享的数据库设计

最近一直在作 基于微信分享的活动.好比说 发起一个分享到微信朋友圈,而后朋友们点击了改分享以后,可以获取什么样的好处.

能够进行抽奖,或者是得到优惠券什么的.因为基本流程大体相同,因此将这一块功能独立处理,做为一个功能组件,称为 微信邀请组件.

数据库设计以下

1 发起邀请记录(邀请函) 字段以下:

activity 邀请活动
FromUserName 微信号
nickname 微信昵称
headimgurl 微信头像
url 邀请函URL
desc 邀请函说明
worth 价值
invited_num 接受邀请次数
invited_total 邀请总次数限制，0为无限制
send_time 发送时间
is_need_subscribed 是否须要微信关注
subscibe_hint_url 关注提示页面连接
personal_receive_num 每人领取次数限制，0为无限制
memo 备注

 

该表的做用就是记录某次活动中产生的邀请记录(,我把它称为邀请函),描述该邀请具有的一些属性.如下是重要字段的说明:

邀请函的拥有人ID,昵称,头像(FromUserName,nickname,headimgurl);

邀请函的价值 worth, 这个价值的意义是随着活动的不一样业务而不一样的. 好比说是积分,好比说是金币,好比说是抽奖机会等等.

邀请函被领取的总次数 invited_total,0为无限制,>0的时候是说明最多有invited_total次能领取该邀请函;

领取邀请函时是否要求领取用户必须是关注微信的用户 is_need_subscribed,有些活动的目的,就是要增粉,因此但愿只有关注过微信的人才能参加这个活动,这个字段就是为这个目的的.

接受邀请次数 invited_num 是随着领取该邀请函的增长而增长的.可是它的值不能超过 invited_total(当 invited_total>0的时候).当 invited_num== invited_total的时候,就是说明该邀请函已满了,没法被领取了.

2 领取邀请记录 字段以下:

activity 邀请活动
invitation_id 邀请函ID
owner_FromUserName 发送邀请的微信ID
owner_nickname 发送邀请的微信昵称
owner_headimgurl 发送邀请的微信头像
got_FromUserName 接受邀请的微信ID
got_nickname 接受邀请的微信昵称
got_headimgurl 接受邀请的微信头像
got_time 接受时间
got_worth 获取价值
memo 备注

 

该表的做用就是记录某次活动某次分享被朋友领取的状况信息,如下是重要字段的说明

获取价值 got_worth,这个价值的意义是随着活动的不一样业务而不一样的. 好比说是积分,好比说是金币,好比说是抽奖机会等等.

邀请函的拥有人ID,昵称,头像(owner_FromUserName,owner_nickname,owner_headimgurl);

领取邀请函的人ID,昵称,头像(got_FromUserName,got_nickname,got_headimgurl);

3 邀请活动 字段以下:

code 编号
name 名称

 

该表的做用就是生成某次活动的信息,好比说 1001 圣诞活动

4 邀请用戶 字段以下:

activity 活动
FromUserName 微信号
nickname 昵称
headimgurl 头像
worth 价值
memo 备注
log_time 记录时间

该表的做用就是记录参与某次活动中全部的用户信息(分享者和接收者),,如下是重要字段的说明:

价值 worth 它的做用不定,它能够表示得到的积分,也能够表示得到的抽奖机会次数等等.这个字段是随着具体活动的业务规则而定.

 

可能某些人会以为疑问,

1 为什么在发起邀请记录(邀请函)和领取邀请记录表中都故意增长了 昵称和头像的字段? 昵称和头像能够经过关联其余表能够得到.

该设计的确是违法了3范式,可是是为了查询性能考虑故意为之, 减小关联操做,能获取更快的查询速度,并且微信头像和昵称通常不会常常变动,这种用空间换取时间的作法在数据库设计中很常见.

2 为什么在发起邀请记录(邀请函) 增长了invited_num的字段,这个值彻底能够从领取邀请记录表里查询出来的?

其实理由 同第一个问题的理由基本上是一致的.若是每次都要到领取邀请记录表去查询某个邀请函被领取的次数的话,查询速度和效率过低下.

3 每每不少系统中已经存在了相似于 邀请用戶表的用户表,好比说会员表等等,因此邀请用戶表有点多余?

的确如此,在我原来的设计中原本是没有该表的,后来增长该表的缘由是为了减小查询,提升性能考虑的.我举个例子.

在某次活动中,业务规则是这样的,发起分享的人能够参加一次抽奖,若是该分享被4我的领过的话,说明该邀请函已满了,那么发起分享的人再增长一次抽奖的机会,同时全部领取该分享的人都增长一次抽奖的机会

因此如何判断某我的具备几回抽奖机会,是一个比较耗时的查询操做.为了减小这个查询,因此增长了该表,而worth字段就是记录了抽奖机会次数.