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

最近一直在做 基于微信分享的活动.比如说 发起一个分享到微信朋友圈,然后朋友们点击了改分享之后,能够获取什么样的好处.

可以进行抽奖,或者是获得优惠券什么的.由于基本流程大致相同,所以将这一块功能独立处理,作为一个功能组件,称为 微信邀请组件.

数据库设计如下

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字段就是记录了抽奖机会次数.

转载于:https://www.cnblogs.com/guoyongrong/p/4217830.html