模板中展示消息后如何存储？存储时机及是否需实现数据库模型

存储操作的执行时机 #

两种执行顺序都有对应的适用场景，根据业务优先级选择即可：

• 优先保障数据可靠性的场景：先存储，后展示
  适用于所有要求消息可追溯、不允许丢失的业务，比如即时通讯、用户留言、系统通知记录等。先完成数据库写入，确认存储成功后再将消息渲染到前端，可完全避免用户前端看到消息、但后续查历史时找不到的异常问题。
• 优先保障交互响应速度的场景：先展示，后存储
  仅适用于对消息可靠性要求极低的非核心场景，比如临时弹窗提示、非重要的全站广播。先把消息渲染到前端，再通过异步任务完成存储，缺点是存储过程一旦出错就会导致历史消息丢失。

是否需要开发对应的数据库模型 #

答案是肯定需要。
结构化存储历史消息必须提前定义对应的数据模型，哪怕使用非关系型数据库存储，也需要明确存储的字段规则，常规的消息模型至少需要包含以下核心字段：

• 消息唯一ID
• 消息所属用户/会话ID
• 消息内容
• 消息类型（文本/图片/文件等）
• 消息生成时间
• 消息状态（已读/未读、是否失效等）
  没有对应模型的话，无法完成结构化写入，后续也没法按用户、时间等维度快速查询历史消息。

内容的提问来源于stack exchange，提问作者Paolo Vezzola