最近一直在做 基於微信分享的活動.比如說 發起一個分享到微信朋友圈,然后朋友們點擊了改分享之后,能夠獲取什么樣的好處.
可以進行抽獎,或者是獲得優惠券什么的.由於基本流程大致相同,所以將這一塊功能獨立處理,作為一個功能組件,稱為 微信邀請組件.
數據庫設計如下
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字段就是記錄了抽獎機會次數.