基於微信分享的數據庫設計

最近一直在作 基於微信分享的活動.好比說 發起一個分享到微信朋友圈,而後朋友們點擊了改分享以後,可以獲取什麼樣的好處.

能夠進行抽獎,或者是得到優惠券什麼的.因爲基本流程大體相同,因此將這一塊功能獨立處理,做爲一個功能組件,稱爲 微信邀請組件.

數據庫設計以下

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字段就是記錄了抽獎機會次數.