如何在不连接数十张表的情况下为保险保单建模
内容提要
文章以保险保单为例，说明文档数据库MongoDB如何弥合业务概念与数据库存储之间的鸿沟。核心设计原则是围绕业务读写方式建模，而非照搬实体关系图。关键决策是“嵌入还是引用”：始终一起读取的数据应嵌入同一文档，如保单中的承保范围、车辆和事件历史；有独立生命周期或跨记录共享的数据应引用，如客户、代理人、产品和理赔。文章还提出应对巨灾场景的异常值模式和哈希分片键，以及计算总额、模式版本化和仅追加历史三种模式。
延伸解读
嵌入与引用的判断标准
文章将文档建模的核心决策简化为两条规则：始终一起读取的数据应嵌入，有独立生命周期或跨记录共享的数据应引用。以保单为例，承保范围、车辆和事件历史嵌入保单文档，因为离开保单它们没有意义；客户、代理人、产品和理赔则引用，因为保单数量大、变更频繁，且理赔可能比保单存续更久。这一判断标准直接来自业务读写方式，而非实体关系图。
巨灾场景下的异常值处理
保险业务面临飓风、山火等极端场景的考验。文章指出，多数理赔附件少于10个，嵌入理赔文档即可；但巨灾后单笔理赔附件可能超过60个，导致文档膨胀并拖慢加载。正确做法是采用异常值模式：默认嵌入，当附件数超过阈值时设置溢出标志，将多余附件移至侧集合。这样既服务了99%的常见情况，又显式处理了1%的例外，避免为少数场景牺牲整体性能。
分片键选择与运营韧性
当数据库需要分片时，分片键的选择直接影响运营韧性。文章以山火理赔激增为例：若按巨灾事件代码分片，活跃山火期间几乎所有新理赔共享同一代码，导致写入集中到单台服务器，恰在吞吐量最关键时形成瓶颈。正确做法是对理赔编号使用哈希分片键，将新理赔均匀分散，同时保留巨灾代码作为普通索引供仪表盘查询。数据模型在风暴来临前就已决定运营韧性。
首日就应采用的三种模式
文章建议在建模初期就采用三种模式：计算总额，将“总发生额”和“总赔付额”直接存储在理赔文档上，避免每次读取时重新汇总；模式版本化，为每份保单和理赔标记版本号，以应对数十年监管保留和诉讼发现带来的文档结构变化；仅追加历史，保单事件、理赔活动以及自动化决策轨迹只能新增、不可编辑或删除，这在保险业是合规要求，尤其当监管关注AI决策时，可审计的轨迹至关重要。
Q&A
保险保单在关系型数据库中通常怎么存储？有什么痛点？
在大多数保险核心系统中，一张保单被切分到几十张关系表中，例如承保范围、车辆、记名方、批单和账单计划各有一张表。每次加载界面时，系统都要通过连接这些表来重新组装保单；每次产品变更时，多张表都需要修改。这种存储方式与业务对保单的理解存在鸿沟。
在文档数据库中，什么时候应该嵌入数据，什么时候应该引用数据？
嵌入那些属于某个对象且总是与该对象一起读取的数据，例如保单中的承保范围、车辆和事件历史。引用那些有独立生命周期或跨多条记录共享的数据，例如客户、代理人、产品和理赔。判断标准是：数据是否总是伴随主体一起读取，以及是否独立存在或共享。
为什么理赔不应该嵌入在保单文档里？
因为理赔可能比产生它的保单存活更久：已取消的保单仍可能有未结理赔。理赔有独立生命周期，应单独存储，并通过引用指向所属保单。
保险理赔遇到大量附件时，如何避免文档过大影响性能？
采用异常值模式：默认嵌入附件，但当理赔附件数量超过阈值时，设置溢出标志，并将多余附件移到侧集合中。这样常见情况保持高效，异常情况被显式处理，避免因少数大理赔拖慢所有屏幕加载。
为什么不能按巨灾事件代码来分片理赔数据？
因为巨灾事件代码会导致热点：在野火等灾害期间，几乎所有新理赔共享同一个巨灾代码，所有新理赔都会路由到同一台服务器，恰好在理赔录入吞吐量最关键的时候造成瓶颈。应使用理赔编号的哈希分片键来均匀分布新理赔，并将巨灾代码保留为普通索引供仪表板查询。
在保险文档模型中，有哪些推荐立即采用的设计模式？
三个模式：1) 计算总额：在理赔文档中存储“总发生额”和“总支付额”，避免每次读取时重新汇总；2) 模式版本化：为每份保单和理赔标记版本号，以应对长期保留和文档结构变化；3) 仅追加历史：保单事件、理赔活动以及自动决策轨迹只能追加，不能编辑或删除，以满足合规和审计要求。
