2019-05-12

网站抽奖系统数据库设计方案

返回

现在很多网站都会有抽奖系统,那么抽奖系统是怎么设计的呢,下面我们就来说说:


1. 我们可以把每个活动抽象出一张表,有具体的活动标题,活动的开始时间,活动的结束时间,因为每个活动限制的用户抽取次数不同,所以有一个抽取次数的限制,还有活动的状态,那么活动表我们起名为t_activity

 

2. 活动的奖励我们可以抽象出一张表,奖励有奖励的类型,红包和积分的具体数额,实物的奖品名称,等等,奖品的等级,是一等奖,二等奖,三等奖,还是纪念奖,还有每个奖品获取的概率,那么物品的表我们起名为t_prize

 

3. 如果是实物奖励的话,需要用户填写一些信息,领取人的姓名,领取人的联系方式,领取人的收获地址t_information;

 

4. 用户每次抽奖的记录,抽到了那个奖项,如果是红包的和积分的话,数额是多少,用户是否领取了奖励,如果是实物的话,抽到了那个实物,是否填写了实物的领取信息,还有抽奖时间t_raffle

 

这就好像我们说的,我有一百个乒乓,其中一个是红色。然后把这些放到一个盒子里面,然后你在进行摸。当你摸完一次以后,在把你摸到的乒乓放回到盒子里面,在进行摸。这些,你每次摸中红色球的概率都是1/100。于是这样就产生的一个问题,我们对奖品会变得不可控制。如果一个运气好,很有可能机会造成奖品还不够发送。如果运气不好,这些奖品永远都可能留在那里。

 

于是根据这种问题,又有一种方法,每一次我们摸中的球,不放回回去了。于是概率也就变成:1/100,1/99,1/98……。这样也就控制了中奖的人数。但是这样又会出现一个问题:作为开奖人我对抽奖时间是不可控的。很多商家希望的是我在每个时间段能发送相应的奖品回去,这样更能提高抽奖的热度。如果一个奖品很快我就发送出去出去了,后面来的人会很失望。

 

于是根据这个问题,又出现了一种方法。如果我们把奖品放到抽奖的数量上面去,那不就可以控制抽奖的时间和中奖的人数了。如果100次抽奖中,我想每隔10次就有一个中奖,于是,我就随机吧中奖的机会放到51621…..这样的抽奖次数去。这样我就能控制抽奖人的那种心情。能把更多的人留在我这里进行抽奖。

 

现在我们来说说关于数据库设计:



 然后我们来说说相关的设计思路:

 

Id:不做说明

 

OpporName:主要是为了区分,例如针对一个奖品我还要进行时间段的区分。所以当设置的奖品多的时候,就不方便区分了。

 

PrizeID:奖品ID

 

PrizeName:奖品名称。

 

PrizeNumber:奖品数量。(方便概率的计算,和奖品的统计。同时如果我对一个设置追加奖品的时候,能更好的使用)

 

OPNumberList:中奖的次数列表。这个是为了吧奖品设置到每次抽奖的次数上面去,如果数量不是很大,就用varchar类型。

 

PTNum:已经抽中的数量,这个也是方便,如果追加奖品能进行计算。同时可以计算奖品的剩余数量。

 

BeginDate:此抽奖概率适用开始时间。

 

EndDate:此抽奖概率适用结束时间。

 

ForeNumber:此次抽奖在前多少次抽奖里面进行选取。因为对于抽奖我们本身对某一时段的抽奖人数是不能拿确认的。一个小时里面,他有可能有100个人,或者有200个人。于是我们设置概率也就不能确认在多少,于是我们选择了在某个时段,前多少次抽奖里面进行选取。例如我在2-3点之间,一般来的人为100-500个人,如果当天来的人只有100个,那么我设置到102这样的次数上面,肯定奖品就只有轮空了。如果我们前100个人之间选,那么我的奖品肯定会配送出去的。

 

AreaID:适于于那些地区。

 

UserID:我指定抽中的为某个人。这个是为了某些公司有自己的托而进行的设置。

 

NowNumber:现在抽奖的次数。

 

OrderID:奖品的概率排序。如果我有多个奖品在一个时间进行了覆盖。我肯定要设置优先把那些奖品分配出去。

 

LotteryExp:领奖的有效时间。

 

OneMaxPriz:每次奖品中奖发放的数量。如果我们每次中奖给2张点卡,等等。

 

States:状态。概率状态。


TAG标签耗时:0.0024280548095703 秒