「SpringCloud」之集成移動(dòng)端推送功能的系統(tǒng)通知數(shù)據(jù)庫(kù)設(shè)計(jì)
系統(tǒng)的通知公告功能似乎是很容易被忽略的功能模塊,在傳統(tǒng)的軟件系統(tǒng)中,一般OA類軟件系統(tǒng)不可或缺,而在應(yīng)用軟件系統(tǒng)中此功能或有或無(wú),在現(xiàn)在大多數(shù)的互聯(lián)網(wǎng)軟件系統(tǒng)中,此功能又必不可缺。所以,在框架設(shè)計(jì)時(shí),我們需要考慮業(yè)務(wù)系統(tǒng)是否需要此功能模塊,然后將此功能作為擴(kuò)展插件,在需要時(shí)開(kāi)啟,在不需要時(shí)配置關(guān)閉即可。
在系統(tǒng)公告設(shè)計(jì)之前,我們需要綜合考慮目前系統(tǒng)通知公告功能都有哪些類型和實(shí)現(xiàn)方式。在類型方面如果是電商類網(wǎng)站,那么系統(tǒng)的通知公告有賬戶變動(dòng)通知、物流變動(dòng)通知、訂單變動(dòng)通知等等;如果是OA類系統(tǒng),那么系統(tǒng)的通知公告有待辦事項(xiàng)、審批通知、公司公告通知等等;在實(shí)現(xiàn)方式方面,有站內(nèi)通知、短信通知、微信通知、APP推送消息等等。
在通知公告的來(lái)源和通知公告的目標(biāo)方面也要做好區(qū)分,通常的通知公告來(lái)源有系統(tǒng)通知、群組通知、用戶通知;相對(duì)于通知公告的目標(biāo)方,有群組、角色、用戶等分類,下面是通知公告功能關(guān)鍵表的E-R圖,不包含RBAC模型關(guān)系,框架支持多租戶:
1、系統(tǒng)公告來(lái)源
系統(tǒng)通知:來(lái)源于某一個(gè)功能模塊或者統(tǒng)一抽象為系統(tǒng)消息,比如賬戶異地登錄、密碼嘗試次數(shù)過(guò)多等,這些顯示來(lái)源于系統(tǒng)消息即可;如果是告警等需要詳細(xì)的來(lái)源時(shí),比如微服務(wù)模式下每個(gè)服務(wù)所引發(fā)的告警等信息,這里需要標(biāo)識(shí)具體的系統(tǒng)來(lái)源模塊。 群組通知:來(lái)源于某一個(gè)部門的的消息,有些消息內(nèi)容是由部門來(lái)統(tǒng)一發(fā)出,比如考勤、放假等通知由行政部門發(fā)出,薪資等相關(guān)內(nèi)容由財(cái)務(wù)部門發(fā)出。 用戶通知:由某一個(gè)人發(fā)出的通知公告,此種情況使用比較少,區(qū)別于用戶對(duì)用戶的私信消息,用戶私信功能需要和系統(tǒng)通知公告功能做好區(qū)分。 數(shù)據(jù)庫(kù)表設(shè)計(jì)公告通知來(lái)源字段:
2、系統(tǒng)公告目標(biāo)
群組目標(biāo):某一公告通知是針對(duì)于群組的,就是某一個(gè)部門內(nèi)的人才能夠收到的消息。 角色目標(biāo):針對(duì)于角色的通知公告,比如某一條通知公告是只發(fā)送給公司內(nèi)部所有的部門經(jīng)理的。 用戶目標(biāo):這個(gè)比較好理解,針對(duì)個(gè)人的消息通知,比如自己的請(qǐng)假申請(qǐng)或者報(bào)銷審批通過(guò)等,系統(tǒng)需要發(fā)送消息到個(gè)人。 數(shù)據(jù)庫(kù)表設(shè)計(jì)公告通知目標(biāo)字段:
3、系統(tǒng)公告級(jí)別
系統(tǒng)通知公告可以根據(jù)情況設(shè)置通知公告的級(jí)別,比如高、中、低,那么在前端提醒的方式就可以采取強(qiáng)制彈框、靜默提醒等方式來(lái)處理這些通知公告。如果是定時(shí)發(fā)送,那么需要設(shè)置定時(shí)任務(wù)根據(jù)發(fā)布時(shí)間來(lái)定時(shí)發(fā)送;如果有消息撤回,那么需要標(biāo)識(shí)已撤回以及消息撤回時(shí)間。
數(shù)據(jù)庫(kù)表設(shè)計(jì)通知公告級(jí)別和發(fā)布時(shí)間字段:
4、系統(tǒng)公告附加內(nèi)容
有些系統(tǒng)的公告通知可能不只是文本消息,基于用戶體驗(yàn)考慮,有些消息到達(dá)時(shí),用戶可以直接通過(guò)點(diǎn)擊通知跳轉(zhuǎn)到具體的業(yè)務(wù)處理模塊,比如工作流的待辦事項(xiàng)、未支付訂單的提醒等等。在現(xiàn)在的APP推送消息中,甚至可以設(shè)置消息通知的縮略圖,那么我們?cè)跀?shù)據(jù)庫(kù)表設(shè)計(jì)的時(shí)候也需要把這些情況考慮進(jìn)去。
數(shù)據(jù)庫(kù)表設(shè)計(jì)通知公告附加字段:
5、系統(tǒng)公告通知渠道
現(xiàn)在移動(dòng)辦公越來(lái)越普遍,針對(duì)于移動(dòng)客戶端的多種方式,那么我們?cè)诎l(fā)送通知公告時(shí)的渠道也是需要有配置的,比如發(fā)送到PC端、APP端、微信小程序端、微信公眾號(hào)通知、短信通知、電話通知等等,有可能是一種,也有可能是多種,那么此時(shí)我們需要為通知公告增加不同的通知渠道。由于是不定數(shù)量的渠道,所以這里我們?cè)黾雨P(guān)聯(lián)表,來(lái)為某一條通知公告設(shè)置通知渠道。默認(rèn)如果不配置渠道,那么都是靜默通知,不彈框也不APP推送。
數(shù)據(jù)庫(kù)表設(shè)計(jì)通知公告通知渠道配置表:
6、系統(tǒng)公告表優(yōu)化
除了完成基本的內(nèi)容表設(shè)計(jì)時(shí),我們還需要考慮數(shù)據(jù)量非常大時(shí)的數(shù)據(jù)庫(kù)設(shè)計(jì)優(yōu)化問(wèn)題。在我們的通知公告中,我們發(fā)現(xiàn)有很多消息是通用消息,是發(fā)送給群組的、角色的,這類消息的內(nèi)容是一致的,如果為每個(gè)用戶都新建一條這樣的通知公告數(shù)據(jù)庫(kù)記錄。那么會(huì)冗余很多無(wú)用數(shù)據(jù)。但是,我們又需要針對(duì)群組、角色中的某一個(gè)用戶標(biāo)識(shí)出通知公告的已讀/未讀狀態(tài)等內(nèi)容,所以此處需要增加關(guān)聯(lián)表,利用關(guān)聯(lián)表來(lái)標(biāo)識(shí)某一個(gè)用戶是否讀取了消息。
數(shù)據(jù)庫(kù)表設(shè)計(jì)通知公告某一用戶的狀態(tài)字段:
通知公告主表完整建表腳本:
系統(tǒng)通知公告通常有系統(tǒng)因業(yè)務(wù)狀態(tài)變化自動(dòng)發(fā)起的通知公告和管理人員通過(guò)后臺(tái)管理主動(dòng)發(fā)起的通知公告。如果是因業(yè)務(wù)狀態(tài)自動(dòng)發(fā)起的通知公告,那么其發(fā)送的渠道需要結(jié)合業(yè)務(wù)需求,在編碼時(shí)確定。如果是管理人員通過(guò)界面發(fā)起的通知公告,那么需要在配置界面提供可選擇的渠道,根據(jù)業(yè)務(wù)需求由發(fā)起人來(lái)確定通過(guò)哪些渠道發(fā)送。
源碼地址: Gitee:https://gitee.com/wmz1930/GitEgg
GitHub:https://github.com/wmz1930/GitEgg