「SpringCloud」之集成移动端推送功能的系统通知数据库设计

  系统通知公告通常有系统因业务状态变化自动发起的通知公告和管理人员通过后台管理主动发起的通知公告。如果是因业务状态自动发起的通知公告，那么其发送的渠道需要结合业务需求，在编码时确定。如果是管理人员通过界面发起的通知公告，那么需要在配置界面提供可选择的渠道，依据业务需求由发起人来确定通过哪些渠道发送。

  系统的通知公告功能似乎是很容易被忽略的功能模块，在传统的软件系统中，一般OA类软件系统不可或缺，而在应用软件系统中此功能或有或无，在现在大多数的互联网软件系统中，此功能又必不可缺。所以，在框架设计时，我们应该考虑业务系统是否需要此功能模块，然后将此功能作为扩展插件，在需要时开启，在不需要时配置关闭即可。

  在系统公告设计之前，我们需要综合考虑目前系统通知公告功能都有哪些类型和实现方式。在类型方面如果是电商类网站，那么系统的通知公告有账户变动通知、物流变动通知、订单变动通知等等；如果是OA类系统，那么系统的通知公告有待办事项、审批通知、公司公告通知等等；在实现方式方面，有站内通知、短信通知、微信通知、APP推送消息等等。

  在通知公告的来源和通知公告的目标方面也要做好区分，通常的通知公告来源有系统通知、群组通知、用户通知；相对于通知公告的目标方，有群组、角色、用户等分类，下面是通知公告功能关键表的E-R图，不包含RBAC模型关系，框架支持多租户：

  系统通知：来源于某一个功能模块或者统一抽象为系统消息，比如账户异地登录、密码尝试次数过多等，这些显示来源于系统消息即可；如果是告警等需要详细的来源时，比如微服务模式下每个服务所引发的告警等信息，这里需要标识具体的系统来源模块。 群组通知：来源于某一个部门的的消息，有些消息内容是由部门来统一发出，比如考勤、放假等通知由行政部门发出，薪资等相关内容由财务部门发出。 用户通知：由某一个人发出的通知公告，此种情况使用比较少，区别于用户对用户的私信消息，用户私信功能需要和系统通知公告功能做好区分。 数据库表设计公告通知来源字段：

  群组目标：某一公告通知是针对于群组的，就是某一个部门内的人才能够收到的消息。 角色目标：针对于角色的通知公告，比如某一条通知公告是只发送给公司内部所有的部门经理的。 用户目标：这个比较好理解，针对个人的消息通知，比如自己的请假申请或者报销审批通过等，系统需要发送消息到个人。 数据库表设计公告通知目标字段：

  系统通知公告可以根据情况设置通知公告的级别，比如高、中、低，那么在前端提醒的方式就可以采取强制弹框、静默提醒等方式来处理这些通知公告。如果是定时发送，那么需要设置定时任务根据发布时间来定时发送；如果有消息撤回，那么需要标识已撤回以及消息撤回时间。

  有些系统的公告通知可能不只是文本消息，基于用户体验考虑，有些消息到达时，用户可以直接通过点击通知跳转到具体的业务处理模块，比如工作流的待办事项、未支付订单的提醒等等。在现在的APP推送消息中，甚至可以设置消息通知的缩略图，那么我们在数据库表设计的时候也需要把这些情况考虑进去。

  现在移动办公越来越普遍，针对于移动客户端的多种方式，那么我们在发送通知公告时的渠道也是需要有配置的，比如发送到PC端、APP端、微信小程序端、微信公众号通知、短信通知、电话通知等等，有可能是一种，也有可能是多种，那么此时我们需要为通知公告增加不同的通知渠道。由于是不定数量的渠道，所以这里我们增加关联表，来为某一条通知公告设置通知渠道。默认如果不配置渠道，那么都是静默通知，不弹框也不APP推送。

  除了完成基本的内容表设计时，我们还需要仔细考虑数据量非常大时的数据库设计优化问题。在我们的通知公告中，我们发现有很多消息是通用消息，是发送给群组的、角色的，这类消息的内容是一致的，如果为每个用户都新建一条这样的通知公告数据库记录。那么会冗余很多无用数据。但是，我们又需要针对群组、角色中的某一个用户标识出通知公告的已读/未读状态等内容，所以此处要增加关联表，利用关联表来标识某一个用户是否读取了消息。

  系统通知公告通常有系统因业务状态变化自动发起的通知公告和管理人员通过后台管理主动发起的通知公告。如果是因业务状态自动发起的通知公告，那么其发送的渠道需要结合业务需求，在编码时确定。如果是管理人员通过界面发起的通知公告，那么需要在配置界面提供可选择的渠道，依据业务需求由发起人来确定通过哪些渠道发送。