系统菜单与按钮国际化升鲜宝多语言数据库设计演进对比文档(一）

系统菜单与按钮国际化升鲜宝多语言数据库设计演进对比文档(一）

基于升鲜宝供应链管理系统原始数据库与当前新方案的对比整理

------ 设计现状、问题与新方案收口对比 ------

|--------------------------------------------------------|
| 适用范围：产品、研发、实施、数据库改造与国际化治理核心结论：原设计属于混合模型，新设计采用分层收口式治理。 |

1. 文档目的

本文用于梳理升鲜宝多语言数据库设计从原有混合式设计到当前分层收口式设计的演进过程，明确原设计解决了什么问题、为什么后续会越来越难维护，以及新设计为什么要按"菜单/按钮、标签、消息、业务数据"拆开治理。

本文同时给出后续数据库、缓存、接口、前后端接入时应遵循的统一边界，作为产品、研发、实施和后续数据库改造的基线文档。

2. 原设计概览

从原始数据库与旧实现文档看，升鲜宝原来的多语言设计不是单一方案，而是逐步叠加出来的混合模型。旧平台最早基于 XML 语言包实现多语言，后续新平台将资源迁移到数据库，并通过"当前语言 + key"方式取值。

原设计至少同时存在四条主线：静态标签翻译、动态通用翻译、业务专用 i18n 子表，以及单据语言上下文。

3. 原设计的四条主线

**3.1 静态标签翻译：**原库存在 sys_static_translation，适用于页面标签、Web/App 静态文案、控件文本等静态资源。

**3.2 动态通用翻译：**原库存在 sys_dynamic_translation，采用 entity_type + entity_id + field_name + language_code 的万能字段翻译模型。

**3.3 业务专用 i18n 子表：**原库已存在 pms_goods_i18n，说明商品域已经开始从万能翻译表向"主表 + i18n 子表"模式演进。

**3.4 单据语言上下文：**很多业务单据表直接保留 language_code 字段，用于记录当前单据显示或操作时的语言环境。

4. 原设计的优点

第一，落地快。对于新增国际化字段，不必立即建专用子表，直接在动态翻译表补数据即可。

第二，已经做了初步分层。静态标签和动态业务翻译至少被区分开，说明当时已经意识到不同类型国际化内容不应完全混用。

第三，商品域已经走向正确方向。pms_goods_i18n 的存在说明原设计后期已经开始向更标准的专表模式靠拢。

5. 原设计的主要问题

**5.1 翻译方式并存太多：**静态翻译表、动态翻译表、业务 i18n 子表、单据 language_code 同时存在，导致后续边界不清晰。

**5.2 动态翻译表太万能：**适合低频兼容，不适合菜单树、字典、商品热列表等高频热路径。

**5.3 菜单国际化没有真正标准化：**后续补充的 sys_language 更像是菜单国际化的补丁方案，而不是原库中统一的一条主线。

**5.4 单据表带 language_code 会扩大耦合：**国际化展示和业务单据直接耦合，不利于后续统一治理和缓存优化。

6. 当前新设计的总体思路

新设计已经明确不再走"一个万能翻译表解决所有问题"的路线，而是按资源类型分层治理。

核心原则包括：菜单/按钮、标签、消息、业务数据分开；热路径不走万能翻译表；sys_language 明确收口，只用于菜单/按钮国际化。

7. 原设计与新设计对比

**7.1 菜单与按钮国际化：**原来依赖通用字段翻译思路；现在明确 sys_language 只服务 sys_menu，并只翻译 menu_name，查询链固定为 sys_role_user -> sys_role_menu -> sys_menu -> sys_language。

**7.2 标签国际化：**原来主要靠静态翻译表与按 key 取值；现在建议独立治理为 UI 资源表，不再与菜单国际化混表。

**7.3 消息提示国际化：**原文档已有 messageCode 思路，但数据库未标准化；现在建议独立为消息模板主表与多语言子表。

**7.4 业务数据国际化：**原来动态翻译表与局部 i18n 子表并存；现在明确业务热点主数据逐步改造为各领域 *_i18n。

**7.5 字典国际化：**原来无标准字典 i18n 子表；现在建议使用 sys_dict_type_i18n 与 sys_dict_data_i18n。

原设计与新设计对比表

|----------|----------------------------------------|-----------------------------------------|
| 设计维度 | 原设计 | 新设计 |
| 菜单/按钮 | 通用字段翻译思路或后续补丁式 sys_language | sys_language 只服务 sys_menu.menu_name |
| 标签 | sys_static_translation + 按 key 取值 | 独立 UI 资源表治理 |
| 消息提示 | 已有 messageCode 思路，但数据库未标准化 | 独立消息模板表与 i18n 子表 |
| 业务数据 | sys_dynamic_translation + 局部 i18n 子表并存 | 热点业务逐步改造为各领域 *_i18n |
| 字典 | 主表/明细表，无标准 i18n 子表 | sys_dict_type_i18n + sys_dict_data_i18n |
| 缓存策略 | 以兼容为主，边界不统一 | 按资源类型分层缓存与精确失效 |
| 总体特点 | 混合模型，能用但难统一 | 分层收口，边界清晰，便于长期治理 |

8. 新设计的最终分层

**8.1 菜单/按钮国际化层：**sys_menu + sys_language，只处理菜单与按钮显示名称。

**8.2 标签国际化层：**sys_static_translation 作为兼容，后续升级为 sys_i18n_ui_resource / sys_i18n_ui_resource_item。

**8.3 消息国际化层：**sys_message_template / sys_message_template_i18n。

**8.4 业务数据国际化层：**各领域 *_i18n，例如 pms_goods_i18n、sys_dict_type_i18n、sys_dict_data_i18n、sys_dept_i18n、sys_post_i18n 等。

9. 设计演进结论

升鲜宝原来的多语言数据库设计，本质上是"静态翻译 + 动态翻译 + 局部业务 i18n + 单据语言上下文"的混合模型。它在早期能快速落地，但随着系统规模扩大，会出现边界混乱、热路径性能不足和治理复杂度上升等问题。

当前新设计则采用按资源类型分层收口的思路：菜单/按钮、标签、消息、业务数据分别治理，其中 sys_language 明确只服务菜单/按钮国际化，其他类型国际化独立建模。

10. 最终建议

短期建议：保持原有静态翻译与动态翻译能力继续兼容，但不再扩大 sys_dynamic_translation 的使用范围；菜单/按钮严格收口到 sys_language。

中期建议：逐步补齐字典、岗位、机构、通知、帮助中心等高频展示主数据的 i18n 子表。

长期建议：形成统一的国际化基础设施，包括语言上下文、双级缓存、版本号失效、页面资源包、消息模板中心与业务主数据 i18n 规范。