我正在参加「启航计划」

  体系的告诉公告功用似乎是很容易被忽略的功用模块，在传统的软件体系中，一般OA类软件体系不可或缺，而在应用软件体系中此功用或有或无，在现在大多数的互联网软件体系中，此功用又必不可缺。所以，在结构规划时，咱们需求考虑事务体系是否需求此功用模块，然后将此功用作为扩展插件，在需求时敞开，在不需求时装备封闭即可。

  在体系公告规划之前，咱们需求归纳考虑目前体系告诉公告功用都有哪些类型和完结方法。在类型方面假如是电商类网站，那么体系的告诉公告有账户改变告诉、物流改变告诉、订单改变告诉等等；假如是OA类体系，那么体系的告诉公告有待办事项、批阅告诉、公司公告告诉等等；在完结方法方面，有站内告诉、短信告诉、微信告诉、APP推送音讯等等。

  在告诉公告的来历和告诉公告的方针方面也要做好差异，一般的告诉公告来历有体系告诉、群组告诉、用户告诉；相对于告诉公告的方针方，有群组、人物、用户等分类，下面是告诉公告功用要害表的E-R图，不包括RBAC模型联系，结构支持多租户：

SpringCloud微服务实战——搭建企业级开发框架（五十一）：集成移动端推送功能的系统通知公告数据库设计

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 = '音讯告诉表';

  体系告诉公告一般有体系因事务状况改变主动发起的告诉公告和办理人员经过后台办理主动发起的告诉公告。假如是因事务状况主动发起的告诉公告，那么其发送的途径需求结合事务需求，在编码时确定。假如是办理人员经过界面发起的告诉公告，那么需求在装备界面供给可选择的途径，依据事务需求由发起人来确定经过哪些途径发送。