SpringCloud微服務實戰——搭建企業級開發框架（五十）：集成移動端推送功能的系統通知公告資料庫設計-有解無憂

??系統的通知公告功能似乎是很容易被忽略的功能模塊，在傳統的軟體系統中，一般OA類軟體系統不可或缺，而在應用軟體系統中此功能或有或無，在現在大多數的互聯網軟體系統中，此功能又必不可缺，所以，在框架設計時，我們需要考慮業務系統是否需要此功能模塊，然后將此功能作為擴展插件，在需要時開啟，在不需要時配置關閉即可，

??在系統公告設計之前，我們需要綜合考慮目前系統通知公告功能都有哪些型別和實作方式，在型別方面如果是電商類網站，那么系統的通知公告有賬戶變動通知、物流變動通知、訂單變動通知等等；如果是OA類系統，那么系統的通知公告有待辦事項、審批通知、公司公告通知等等；在實作方式方面，有站內通知、短信通知、微信通知、APP推送訊息等等，

??在通知公告的來源和通知公告的目標方面也要做好區分，通常的通知公告來源有系統通知、群組通知、用戶通知；相對于通知公告的目標方，有群組、角色、用戶等分類，下面是通知公告功能關鍵表的E-R圖，不包含RBAC模型關系，框架支持多租戶：

通知公告關鍵表的E-R圖

1、系統公告來源

系統通知：來源于某一個功能模塊或者統一抽象為系統訊息，比如賬戶異地登錄、密碼嘗試次數過多等，這些顯示來源于系統訊息即可；如果是告警等需要詳細的來源時，比如微服務模式下每個服務所引發的告警等資訊，這里需要標識具體的系統來源模塊，
群組通知：來源于某一個部門的的訊息，有些訊息內容是由部門來統一發出，比如考勤、放假等通知由行政部門發出，薪資等相關內容由財務部門發出，
用戶通知：由某一個人發出的通知公告，此種情況使用比較少，區別于用戶對用戶的私信訊息，用戶私信功能需要和系統通知公告功能做好區分，

資料庫表設計公告通知來源欄位：

    `message_category` VARCHAR(32)    COMMENT '系統公告 待辦訊息  賬戶通知 關注/收藏/點贊通知' ,
    `receive_type` VARCHAR(32)    COMMENT '接收訊息型別 全員  組  角色  用戶' ,
    `to_organization_id` BIGINT(20)    COMMENT '接收訊息的群組' ,
    `to_role_id` BIGINT(20)    COMMENT '接收訊息的角色' ,
    `to_user_id` BIGINT(20)    COMMENT '接收訊息的用戶' ,

2、系統公告目標

群組目標：某一公告通知是針對于群組的，就是某一個部門內的人才能夠收到的訊息，
角色目標：針對于角色的通知公告，比如某一條通知公告是只發送給公司內部所有的部門經理的，
用戶目標：這個比較好理解，針對個人的訊息通知，比如自己的請假申請或者報銷審批通過等，系統需要發送訊息到個人，

資料庫表設計公告通知目標欄位：

    `send_from_type` VARCHAR(32)    COMMENT '訊息來源型別 系統 組  用戶' ,
    `from_group_id` BIGINT(20)    COMMENT '發送訊息的組' ,
    `from_user_id` BIGINT(20)    COMMENT '發送訊息的用戶' ,
    `from_system` VARCHAR(32)    COMMENT '發送訊息的系統' ,

3、系統公告級別

??系統通知公告可以根據情況設定通知公告的級別，比如高、中、低，那么在前端提醒的方式就可以采取強制彈框、靜默提醒等方式來處理這些通知公告，如果是定時發送，那么需要設定定時任務根據發布時間來定時發送；如果有訊息撤回，那么需要標識已撤回以及訊息撤回時間，

資料庫表設計通知公告級別和發布時間欄位：

    `publish_time` DATETIME    COMMENT '發布時間' ,
    `recall_flag` TINYINT(2)    COMMENT '是否撤回' ,
    `recall_time` DATETIME    COMMENT '撤回時間' ,
    `message_level` VARCHAR(32)    COMMENT '訊息級別  高 中 低' ,

4、系統公告附加內容

??有些系統的公告通知可能不只是文本訊息，基于用戶體驗考慮，有些訊息到達時，用戶可以直接通過點擊通知跳轉到具體的業務處理模塊，比如作業流的待辦事項、未支付訂單的提醒等等，在現在的APP推送訊息中，甚至可以設定訊息通知的縮略圖，那么我們在資料庫表設計的時候也需要把這些情況考慮進去，

資料庫表設計通知公告附加欄位：

`title` VARCHAR(100)    COMMENT '標題' ,
`content` VARCHAR(1000)    COMMENT '內容' ,
`redirect_url` VARCHAR(255)    COMMENT '跳轉鏈接' ,
`image_url` VARCHAR(255)    COMMENT '訊息圖片' ,
......
 `publish_time` DATETIME    COMMENT '發布時間' ,
 `recall_flag` TINYINT(2)    COMMENT '是否撤回' ,
 `recall_time` DATETIME    COMMENT '撤回時間' ,
 `message_level` VARCHAR(32)    COMMENT '訊息級別  高 中 低' ,

5、系統公告通知渠道

??現在移動辦公越來越普遍，針對于移動客戶端的多種方式，那么我們在發送通知公告時的渠道也是需要有配置的，比如發送到PC端、APP端、微信小程式端、微信公眾號通知、短信通知、電話通知等等，有可能是一種，也有可能是多種，那么此時我們需要為通知公告增加不同的通知渠道，由于是不定數量的渠道，所以這里我們增加關聯表，來為某一條通知公告設定通知渠道，默認如果不配置渠道，那么都是靜默通知，不彈框也不APP推送，

資料庫表設計通知公告通知渠道配置表：

CREATE TABLE t_sys_message_channel(
    `id` VARCHAR(32)    COMMENT '主鍵' ,
    `tenant_id` BIGINNT(20)    COMMENT '租戶id' ,
    `message_id` VARCHAR(32)    COMMENT '系統訊息id' ,
    `message_channel_type` VARCHAR(32)    COMMENT '渠道型別（短信、電話、APP PUSH等）' ,
    `channel_redirect_url` VARCHAR(255)    COMMENT '本渠道的跳轉鏈接' ,
    `channel_image_url` VARCHAR(255)    COMMENT '本渠道的圖片' ,
    `creator` BIGINNT(20)    COMMENT '創建者' ,
    `create_time` DATETIME    COMMENT '創建時間' ,
    `operator` BIGINNT(20)    COMMENT '更新者' ,
    `update_time` DATETIME    COMMENT '更新時間' ,
    `del_flag` tinyint(2)    COMMENT '是否洗掉' 
)  COMMENT = '通知渠道和系統訊息關聯表';

6、系統公告表優化

??除了完成基本的內容表設計時，我們還需要考慮資料量非常大時的資料庫設計優化問題，在我們的通知公告中，我們發現有很多訊息是通用訊息，是發送給群組的、角色的，這類訊息的內容是一致的，如果為每個用戶都新建一條這樣的通知公告資料庫記錄，那么會冗余很多無用資料，但是，我們又需要針對群組、角色中的某一個用戶標識出通知公告的已讀/未讀狀態等內容，所以此處需要增加關聯表，利用關聯表來標識某一個用戶是否讀取了訊息，

資料庫表設計通知公告某一用戶的狀態欄位：

CREATE TABLE t_sys_message_user(
    `id` VARCHAR(32)    COMMENT '主鍵' ,
    `tenant_id` BIGINNT(20)    COMMENT '租戶id' ,
    `user_id` BIGINNT(20)    COMMENT '用戶id' ,
    `message_id` VARCHAR(32)    COMMENT '系統訊息id' ,
    `read_already` VARCHAR(32)    COMMENT '是否已讀' ,
    `creator` BIGINNT(20)    COMMENT '創建者' ,
    `create_time` DATETIME    COMMENT '創建時間' ,
    `operator` BIGINNT(20)    COMMENT '更新者' ,
    `update_time` DATETIME    COMMENT '更新時間' ,
    `del_flag` tinyint(2)    COMMENT '是否洗掉' 
)  COMMENT = '用戶和系統訊息關聯表';

通知公告主表完整建表腳本:

CREATE TABLE t_sys_message(
    `id` VARCHAR(32) NOT NULL   COMMENT '主鍵（雪花演算法）' ,
    `tenant_id` BIGINT(20)    COMMENT '租戶號' ,
    `title` VARCHAR(100)    COMMENT '標題' ,
    `content` VARCHAR(1000)    COMMENT '內容' ,
    `redirect_url` VARCHAR(255)    COMMENT '跳轉鏈接' ,
    `image_url` VARCHAR(255)    COMMENT '訊息圖片' ,
    `message_category` VARCHAR(32)    COMMENT '系統公告 待辦訊息  賬戶通知 關注/收藏/點贊通知' ,
    `receive_type` VARCHAR(32)    COMMENT '接收訊息型別 全員  組  角色  用戶' ,
    `to_organization_id` BIGINT(20)    COMMENT '接收訊息的群組' ,
    `to_role_id` BIGINT(20)    COMMENT '接收訊息的角色' ,
    `to_user_id` BIGINT(20)    COMMENT '接收訊息的用戶' ,
    `send_from_type` VARCHAR(32)    COMMENT '訊息來源型別 系統 組  用戶' ,
    `from_group_id` BIGINT(20)    COMMENT '發送訊息的組' ,
    `from_user_id` BIGINT(20)    COMMENT '發送訊息的用戶' ,
    `from_system` VARCHAR(32)    COMMENT '發送訊息的系統' ,
    `publish_time` DATETIME    COMMENT '發布時間' ,
    `recall_flag` TINYINT(2)    COMMENT '是否撤回' ,
    `recall_time` DATETIME    COMMENT '撤回時間' ,
    `message_level` VARCHAR(32)    COMMENT '訊息級別  高 中 低' ,
    `creator` BIGINT(20)    COMMENT '創建人' ,
    `create_time` DATETIME    COMMENT '創建時間' ,
    `operator` BIGINT(20)    COMMENT '更新人' ,
    `update_time` DATETIME    COMMENT '更新時間' ,
    `del_flag` TINYINT(2) NOT NULL   COMMENT '是否洗掉' ,
    PRIMARY KEY (id)
)  COMMENT = '訊息通知表';

??系統通知公告通常有系統因業務狀態變化自動發起的通知公告和管理人員通過后臺管理主動發起的通知公告，如果是因業務狀態自動發起的通知公告，那么其發送的渠道需要結合業務需求，在編碼時確定，如果是管理人員通過界面發起的通知公告，那么需要在配置界面提供可選擇的渠道，根據業務需求由發起人來確定通過哪些渠道發送，

原始碼地址:

Gitee: https://gitee.com/wmz1930/GitEgg

GitHub: https://github.com/wmz1930/GitEgg

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/546133.html

標籤：其他

上一篇：怎么用訊息佇列實作分布式事務？

下一篇：java代碼自動生成帶swagger3注解