系统的集成计通知公告功能似乎是很容易被忽略的功能模块，在传统的移动软件系统中，一般OA类软件系统不可或缺，端推而在应用软件系统中此功能或有或无，送功数据在现在大多数的系统互联网软件系统中，此功能又必不可缺。通知所以，库设在框架设计时，集成计我们需要考虑业务系统是移动否需要此功能模块，然后将此功能作为扩展插件，端推在需要时开启，送功数据在不需要时配置关闭即可。系统
在系统公告设计之前，通知我们需要综合考虑目前系统通知公告功能都有哪些类型和实现方式。库设在类型方面如果是集成计电商类网站，那么系统的通知公告有账户变动通知、物流变动通知、订单变动通知等等；如果是OA类系统，那么系统的通知公告有待办事项、审批通知、公司公告通知等等；在实现方式方面，有站内通知、短信通知、微信通知、服务器租用APP推送消息等等。
在通知公告的来源和通知公告的目标方面也要做好区分，通常的通知公告来源有系统通知、群组通知、用户通知；相对于通知公告的目标方，有群组、角色、用户等分类，下面是通知公告功能关键表的E-R图，不包含RBAC模型关系，框架支持多租户：
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 接收消息的用户 ,1.2.3.4.5. 2、系统公告目标群组目标：某一公告通知是针对于群组的，就是某一个部门内的人才能够收到的消息。 角色目标：针对于角色的通知公告，比如某一条通知公告是只发送给公司内部所有的部门经理的。 用户目标：这个比较好理解，针对个人的消息通知，比如自己的请假申请或者报销审批通过等，系统需要发送消息到个人。 数据库表设计公告通知目标字段：
复制`send_from_type` VARCHAR(32) COMMENT 消息来源类型 系统 组 用户 ,`from_group_id` BIGINT(20) COMMENT 发送消息的组 ,`from_user_id` BIGINT(20) COMMENT 发送消息的亿华云计算用户 ,`from_system` VARCHAR(32) COMMENT 发送消息的系统 ,1.2.3.4. 3、系统公告级别系统通知公告可以根据情况设置通知公告的级别，比如高、中、低，那么在前端提醒的方式就可以采取强制弹框、静默提醒等方式来处理这些通知公告。如果是定时发送，那么需要设置定时任务根据发布时间来定时发送；如果有消息撤回，那么需要标识已撤回以及消息撤回时间。
数据库表设计通知公告级别和发布时间字段：
复制`publish_time` DATETIME COMMENT 发布时间 ,`recall_flag` TINYINT(2) COMMENT 是否撤回 ,`recall_time` DATETIME COMMENT 撤回时间 ,`message_level` VARCHAR(32) COMMENT 消息级别 高 中 低 ,1.2.3.4. 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 消息级别 高 中 低 ,1.2.3.4.5.6.7.8.9. 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 = 通知渠道和系统消息关联表;1.2.3.4.5.6.7.8.9.10.11.12.13. 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 = 用户和系统消息关联表;1.2.3.4.5.6.7.8.9.10.11.12.通知公告主表完整建表脚本:
复制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 = 消息通知表;1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.系统通知公告通常有系统因业务状态变化自动发起的通知公告和管理人员通过后台管理主动发起的通知公告。如果是因业务状态自动发起的通知公告，那么其发送的渠道需要结合业务需求，在编码时确定。如果是管理人员通过界面发起的通知公告，那么需要在配置界面提供可选择的渠道，根据业务需求由发起人来确定通过哪些渠道发送。
源码地址: Gitee:https://gitee.com/wmz1930/GitEgg
GitHub:https://github.com/wmz1930/GitEgg
(责任编辑：IT科技)