同一时间仅关联单个实体的多关联中心实体设计替代方案咨询

你之前采用的单中心表多外键设计，本质是将不同类型实体的关联字段全部堆叠在同一张表中，会产生大量空值、且表结构会随实体类型增加持续膨胀，也就是上级指出的信息过载问题。可采用泛化关联的架构设计进行优化，完全满足你「统一本地ID、字段缓存、按需补全源API数据」的核心需求：

表结构设计 #

通用实体主表（替代原有臃肿中心表） #

仅保留所有实体通用的公共字段，无冗余空置字段：

• local_id：主键，全局唯一的本地ID，实现所有实体的统一标识管理
• entity_type：枚举类型，标记实体对应的来源API/实体分类，例如API_A_USER、API_B_ORDER
• origin_id：存储该实体在源API侧的原始ID，用于后续请求源API补全数据
• cached_fields：JSON类型字段，存储需要缓存的异构实体字段，无需提前预设列结构
• last_sync_time：最后一次从源API同步数据的时间，用于判断缓存有效性
• created_at、updated_at：通用时间戳字段

可选类型扩展表 #

如果某类实体存在大量需要结构化查询的专属字段，可单独创建对应类型的扩展表，以local_id作为主键和通用实体主表关联即可；无结构化查询需求的实体直接用主表的cached_fields存储缓存字段，无需额外建表。

业务逻辑实现要点 #

• 缓存校验：接收实体查询请求时，先根据last_sync_time判断缓存是否在有效期内，再校验当前请求所需字段是否全部存在于cached_fields中，两个条件都满足则直接返回缓存数据。
• 按需补全：缓存过期或缺少所需字段时，根据entity_type路由到对应源API的请求逻辑，携带origin_id拉取源端全量数据，更新cached_fields和last_sync_time后再返回结果。

方案优势 #

• 表结构稳定：新增不同来源的实体类型时，仅需要新增entity_type枚举值即可，无需修改主表结构，不会产生空置字段。
• 适配性强：JSON类型的缓存字段可灵活适配不同源API的异构字段结构，不需要提前为不同实体预设专属列。
• 维护成本低：核心管理逻辑全部基于通用主表实现，新增实体类型仅需要补充对应源API的拉取逻辑即可，无需修改核心流程。

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