达梦 DM8、openGauss、人大金仓怎么选？RuoYi Office 国产数据库适配与验收指南

达梦 DM8、openGauss、人大金仓怎么选？RuoYi Office 国产数据库适配与验收指南

🌐 文档地址 ：https://ruoyioffice.com

👇 文章底部获取源码和演示地址 👇

💬 ：17156169080（获取产品咨询）
政企选型需要把数据库名称、目标版本和实际产品证据放在一起判断。本文结合 RuoYi Office 的达梦、openGauss 实验结果与人大金仓框架能力，说明怎样区分框架支持、实库运行和业务闭环，并把选型结论转成可执行的现场验收。

▲ 阶梯表示证据深度，不表示数据库性能排名：达梦已有代表审批闭环，openGauss 验证至填报，人大金仓本轮属于框架支持。

引言："支持国产库"这句话，还缺哪些信息？

同一个"支持"可能指项目里有驱动，也可能指现场能登录，或者指某条业务流程已经完整跑通。采购

方若不追问验证条件，就很难把宣传文字变成验收条款。

数据库名称相同，版本、兼容模式、CPU 架构、JDK 和应用模块仍可能不同。技术负责人需要判断的

是一组环境与业务组合，而非孤立品牌。

常见说法	还应补充的内容	对选型的影响
支持达梦	版本、schema、代表流程	能否复用已验证路径
PG 兼容	驱动、认证、模式、引擎识别	迁移成本与差异点
框架支持金仓	是否做过指定版本实库回归	现场验证工作量
已通过适配	环境组合、通过用例、排除项	验收范围是否一致
私有化部署	数据、网络、文件与运维边界	是否符合现场要求

本文不做未经测试的性能排名，而是回答更可落地的问题：哪些证据能复用，哪些仍需在现场取得。

一、用三个产品关口理解验证深度

RuoYi Office 的企业工作台、业务表单和流程详情，为采购与实施双方提供共同语言。管理人员能

看懂页面结果，开发人员也能把结果对应到接口与数据。

1. 登录：基础身份与权限是否可用

▲ 既有开发环境真实工作台，用于说明登录验收内容；不依据图片推断数据库类型。

登录验证用户、组织、角色、菜单和会话的基本链路。只取得 token，还应打开工作台与客户需要的

模块入口。

"管理员能登录"也不能代表普通员工权限正确。现场最好补一名代表角色，检查菜单范围与可见数据

。

2. 填报：业务资料与字段是否正确

▲ 既有开发环境真实业务表单。国产库验收应检查中文、时间、关联选择项与必填规则，不能只要求页面打开。

填报包含查询印章、读取人员与部门、展示日期时间和业务规则。字段可输入且信息正确，说明验证

已经深入产品使用场景。

但填报仍不包含流程创建与审批写入，不能因为下一步按钮存在就提前判定业务闭环通过。

3. 审批：结果是否回到原业务单

▲ 既有开发环境费用申请的审批轨迹，用于说明现场检查方式；不是国产库实拍，历史结论来自对应环境记录。

审批关口覆盖实例创建、任务分配、意见、历史与业务回写。应该同时查看流程历史状态与业务审批

状态，不以一次按钮成功提示作为最终结论。

对于用印，还应区分审批授权与实际用章执行。客户若要求借章归还验收，应另加执行用例，而不是

扩大既有审批证据的含义。

二、当前三类数据库各有什么依据

1. 达梦 DM8：已有代表业务闭环

实验环境采用 DM8 官方 x86_64 容器、专用 JDBC 驱动、明确 schema 与主键策略。2026 年 9 月

记录覆盖导入、启动、登录、用印提交和多级审批。

最终核对到业务审批状态 2 与流程 completed。这使达梦路径在当前三库中具备最完整的代表业务

证据。

这种完整性指的是指定版本与代表流程，不是对客户所有业务、性能或容灾要求的承诺。

2. openGauss：已有实库运行与填报证据

openGauss 5.0.0 已完成导入、官方 JDBC 接入、应用启动、登录、流程资源恢复与发布，以及用印

填报。

本轮没有把完整审批作为最终通过项。因此现场若采用 openGauss，仍需取得提交、审批与业务回写

的直接证据。

已有工程处理可以复用，但验收状态需要来自目标环境实际结果。

3. 人大金仓：框架具备接入能力，实库仍需验收

当前工程包含 Kingbase JDBC、数据库枚举、主键序列路径及方言适配等能力。本轮实验室没有取得

人大金仓实库验收结果。

框架能力能降低接入工作量，但客户指定版本、兼容模式、认证与应用模块仍需验证。不能把 Postg

reSQL 对照结果写成金仓通过证明。

目标库	已有能力或结果	首要现场补充
达梦 DM8	导入、运行、用印审批闭环	客户版本及启用模块回归
openGauss	导入、登录、发布、填报	代表流程提交与审批
人大金仓	驱动、方言、序列等框架能力	指定版本实库完整路径
PostgreSQL	对照环境审批闭环	用于分析差异，不作国产库认证

三、先定环境组合，再谈迁移成本

1. 采购要求决定可选集合

客户指定数据库、操作系统和硬件时，选型应从这些明确条件出发。若名单要求某个版本，不能用另

一个版本的实验记录替代。

如果没有指定数据库，可以结合既有许可证、运维技能、备份体系和业务范围评估，而不是只比较转

换脚本数量。

决策维度	需要确认的事实	影响
采购名单	厂商与具体版本	能否满足约束
CPU / OS	架构、系统发行版	介质与本地组件可用性
运维能力	备份、恢复、监控、值守	上线后保障成本
业务范围	财务、审批、报表、文件等	回归用例规模
集成组件	办公套件、身份系统等	网络与对接工作量
交付期限	可复用证据与待验证项	排期风险

2. 分清软件兼容与正式认证

工程验证回答"这组软件和业务有没有跑通"。厂商互认证或正式测评回答的是另外一组要求，通常绑

定明确版本与对象。

软件实验室可以提供部署、接口、数据库和流程证据，但不能据此生成不存在的证书或扩展到未测试

的国产整机。

RuoYi Office 的当前实验室采用 x86_64。鲲鹏、飞腾等架构需要配套介质与实测，不能只因为应用

使用 Java 就省略涉及本地库的检查。

3. 国产中间件替换要按运行形态判断

Tengine 是已验证 Web 接入层，Spring Boot 采用内嵌容器运行。客户要求 TongWeb、BES 等应用

服务器时，应确认对应运行形态与 WAR 适配工作。

同样，使用国产数据库不自动替换 Redis、办公预览组件或外部模型。应按项目清单分别确认，而非

把一个组件通过扩大为全栈通过。

四、把支持范围转成验收数据模型

1. 一个结论必须绑定环境、用例与证据

▲ 建议的交付证据模型，不是平台已经内置的验收管理模块：环境组合执行用例，结果引用对应证据，报告据此限定结论。

证据字段	建议内容	用途
环境身份	数据库版本、OS、CPU、JDK	避免不同环境结果混用
应用与数据基线	应用包、schema、static_data	解释版本是否配套
用例身份	登录、填报、提交、审批	说明实际验证对象
实际状态	PASS / FAIL / PARTIAL / NOT_TESTED	防止未执行项变为通过
证据引用	日志、接口结果、单据身份	支撑复核
验证时间	本次执行日期	判断证据时效

当前实验记录使用明确状态值。建议客户验收沿用同类状态模型，并把"部分通过"写清楚已执行到哪

一步。

2. 用只读查询核对定义与业务身份

下面是建议的只读检查示例，针对已有测试单据。它不创建流程、不修改数据；实施人员应先切换到

正确 schema，并传入自己获准的单号。

-- 只读示例：先确认当前账号与 schema
SELECT COUNT(*) AS deployment_count
FROM ACT_RE_DEPLOYMENT;
SELECT COUNT(*) AS definition_count
FROM ACT_RE_PROCDEF;

-- 明确验证对象，不用总数替代指定流程
SELECT ID_, KEY_, VERSION_, SUSPENSION_STATE_
FROM ACT_RE_PROCDEF
WHERE KEY_ = 'oa_seal_apply_bill';

-- 单号替换为获准的实际测试样本
SELECT id, bill_code, process_instance_id,
       process_status, use_status
FROM oa_seal_apply_bill
WHERE bill_code = 'OA103-2026090300004';

-- 再按上一步取得的实例 ID 核对历史状态
SELECT ID_, BUSINESS_KEY_, STATE_
FROM ACT_HI_PROCINST
WHERE ID_ = '<实际流程实例ID>';

表级计数和单据级状态分开查询，是为了避免"总数正常"掩盖当前代表记录的关联问题。查询结果仍

要与具体应用操作对应。

资源字节完整性、审批角色权限与附件访问，需要另外的检查，不能由这几条 SQL 自动推出。

3. 状态汇总不应把缺证据当成通过

下面给出一个验收报告汇总的设计示例，说明如何保留未测试状态。它是交付团队可以采用的检查规

则，不是声称 RuoYi Office 已提供这段验收系统功能。

def summarize(results, required):
    # 建议的报告汇总规则，并非平台现成功能
    allowed = {"PASS", "FAIL", "PARTIAL", "BLOCKED", "NOT_TESTED"}
    if not required:
        return {"status": "NOT_TESTED", "missing": []}
    states = {key: results.get(key, "NOT_TESTED") for key in required}
    invalid = [key for key, state in states.items() if state not in allowed]
    if invalid:
        raise ValueError(f"invalid status: {invalid}")
    failed = [key for key, state in states.items() if state == "FAIL"]
    blocked = [key for key, state in states.items() if state == "BLOCKED"]
    missing = [key for key, state in states.items() if state == "NOT_TESTED"]
    partial = [key for key, state in states.items() if state == "PARTIAL"]
    status = "PASS"
    if failed or blocked:
        status = "FAIL" if failed else "BLOCKED"
    elif missing or partial:
        status = "PARTIAL"
    return {"status": status, "missing": missing, "partial": partial}

NOT_TESTED 应提示继续补测，FAIL 应提示修复，PARTIAL 应说明剩余环节。不同状态承担不

同决策，不能统称"基本没问题"。

五、框架层提供什么，仍要现场观察什么

1. 主键策略说明了新增路径

当前框架区分整数自增和序列输入路径，信创 Profile 也会明确主键策略。下面摘取实际处理逻辑

，说明框架具备按数据库选择策略的能力。

public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) {
    DbType dbType = getDbType(environment);
    if (dbType == null) {
        return;
    }
    setJobStoreDriverIfPresent(environment, dbType);
    IdType idType = getIdType(environment);
    if (idType != IdType.NONE) {
        return;
    }
    if (INPUT_ID_TYPES.contains(dbType)) {
        setIdType(environment, IdType.INPUT);
        return;
    }
    setIdType(environment, IdType.AUTO);
}

INPUT 与 @KeySequence 配套使用，表示框架需要在插入前取得 ID；不应理解成要求员工手工

填写数据库主键。

Profile 显式指定的策略不会被该逻辑再次自动改写。即使框架具备选择能力，初始化表与序列仍需

匹配，已有数据也需要校准。

2. 方言函数应通过实际业务查询观察

当前数据库枚举对集合查询提供不同表达式，达梦和 PG 类数据库走不同实现路径。它能处理已纳入

封装的查询，不代表项目所有 SQL 都天然跨库。

对财务、报表或复杂分页，应选客户会实际使用的页面核对。若运行时 SQL 包含数据库专用函数，

要判断兼容函数、Mapper 或业务算法哪一层负责。

决策点	建议选择	依据
优先复用哪条路径	与客户指定环境最接近的实测组合	减少无关变化
第一条代表流程	字段、角色与状态较完整的业务单	覆盖读写与回调
验收状态	保留 PASS / PARTIAL / NOT_TESTED	不吞掉差异
复杂模块验证	按启用模块安排	核心通过不扩展为全模块
升级后复测	数据库、应用或驱动变化时执行	历史证据可能失效

六、现场验收怎样排序更有效

▲ 先固定环境与数据基线，再执行产品用例；证据汇总支持选型和交付结论，不能反向替代实际执行。

1. 先验证基础链路，再增加模块

先确认数据导入、应用健康和登录，随后检查表单、代表提交与审批。基本链路未通时，同时测试全

部模块会产生大量重复错误，难以判断共同根因。

通过代表闭环后，再按客户实际启用的财务、合同、HRM、ERP 等模块展开。对文件、在线编辑、短

信和外部身份系统，增加对应集成用例。

2. 正常路径和异常路径分别记录

审批通过代表正常授权路径，拒绝、撤回、启动失败和重复提交验证恢复与边界。客户可以按合同和

实际业务选择，但选入验收后必须分别给结果。

故障用例不需要为每个技术细节发明一条大场景。优先选择用户会遇到、且会影响业务身份和状态一

致性的失败。

3. 数据库选择与运维选择一起评估

如果现场团队已经拥有成熟备份恢复体系，应把这份能力放进选型。迁移成本之外，还有持续升级、

容量、故障排查和恢复演练成本。

实验室的启动耗时与虚拟机规格不能直接用于估算客户生产容量。生产资源应根据并发、数据量、模

块和集成组件单独评估。

七、给采购与实施双方的最小验收表

验收对象	操作	通过证据
版本组合	核对数据库、OS、JDK、应用	版本记录一致
基础身份	登录代表角色	工作台与菜单正确
业务字段	打开并填写代表单	中文、时间、选择项正确
业务提交	提交获准测试单	单号、实例、任务有关联
审批回写	完成选定审批路径	流程与业务状态一致
文件链路	打开代表附件	内容与权限正确
恢复能力	执行获准恢复演练	数据与文件配套恢复

这张表可以按项目裁剪，但必须写明删去了哪些检查。删去的检查不应仍然出现在"已通过全部能力"

的结论里。

以一份采购要求为例：怎样形成双方都能签字的结论

假设客户要求国产服务器操作系统、指定国产数据库，以及 OA 和流程审批。

首先把约束拆成软件版本、部署形态、业务范围与运行保障，而不是直接给出"全部支持"的回答。

先识别必须满足与可以协商的部分

采购明确列出的厂商和版本属于必须满足项。

客户没有限定的接入层、缓存和部署形态，可以讨论推荐组合。

对于指定商业应用服务器，需要明确是否接受内嵌容器，或必须采用对应 WAR 形态。

这项差异影响实施工作量，不能等部署完成后才发现双方理解不同。

把代表业务描述成可执行动作

"支持 OA"范围过大，验收人员无法直接执行。

可以先选"员工发起用印申请，部门领导与保管员处理，业务单同步结果"作为代表路径。

再把字段、角色、输入样本和结果条件写清楚。

若客户要求附件、外借和归还，把这些动作分别列入；没有选择的动作就不进入通过结论。

一个写得清楚的小闭环，比一张很长却无法执行的功能清单更有验收价值。

把已有证据与现场新增证据分开

达梦已有实验闭环，可作为方案依据与复用起点。

客户指定另一数据库版本时，还需取得版本差异下的现场证据。

openGauss 已有填报结果，现场应继续取得提交和审批结果。

人大金仓从框架能力出发，安排完整实库路径。

这三种起点不同，应体现在排期与技术任务中，而不是统一承诺同样天数。

项目条件	可以复用的内容	必须现场取得
达梦相近版本	导入、Profile、代表流程方法	指定版本实际结果
openGauss 指定版本	驱动与引擎适配方法	完整业务闭环
人大金仓	框架驱动、序列与方言能力	初始化到审批的实库证据
国产整机	Java 应用部署方法	对应架构介质与实际运行
商业中间件	产品业务用例	指定运行形态适配

让验收问题可以定位，而不只是失败

一个用例没有通过，应保留失败阶段。

登录失败和审批回调失败，技术处理完全不同；两者不应只得到同一个"国产化不兼容"的标签。

记录请求、环境、业务身份和首个异常后，双方可以判断是否需要配置修正、数据升级或代码适配。

这样也能防止某个外部组件网络不通，被错误归因到国产数据库。

通过条件不要含糊

"系统稳定运行"需要可观察定义，例如在约定用例范围内无阻断错误，并取得指定业务结果。

"性能良好"则需要约定数据量、并发、资源与指标，不能用实验室一次启动时间替代。

"可以恢复"应执行恢复演练，不能只证明备份文件存在。

这些要求越具体，越容易控制项目范围和减少争议。

模糊条款	建议改写方向
支持全部国产库	指定数据库与版本的验收组合
审批功能正常	指定模型、角色与业务结果
数据完整	结构、内容、关联与新写入检查
性能达到要求	约定资源、负载与指标
提供备份	明确范围、周期与恢复演练
已经认证	指明正式文件及绑定对象

将待验证项保留在计划里

没有取得证据的能力，应列出负责方、目标环境和验证时机。

待验证不表示永远不能支持，而是表示当前承诺必须带条件。

客户确认这些条件后，技术团队就能按相同清单推进，而不必在每次沟通时重新解释"支持"的含义。

选型完成的标志，是约束、方案、用例与证据之间形成一条能够签字的对应关系。

证据过期时，怎样恢复可信状态

一次通过结果绑定当时的环境与数据，不适合永久作为所有后续版本的依据。

应用、驱动或数据库升级后，应按变化范围复测，并保留新的执行日期。

旧证据可以保留用于说明演进来源，但不能覆盖新环境的未测试状态。

若客户换了操作系统或 CPU 架构，还应核对介质、本地依赖和实际运行条件。

建议报告明确"复用历史方法"与"取得本次结果"两栏，避免把二者写成同一件事。

对于未启用模块，可以在范围说明中排除，但不能把必测步骤改成未启用来获得通过结论。

例如本项目要求审批闭环，填报完成之后的提交与审批就不能被豁免。

证据状态随环境变化更新，选型结论才具备持续维护的基础。

八、快速体验

在线演示：https://ruoyioffice.com/web/

账号 admin / admin123。技术负责人可先查看工作台、用印详情与审批轨迹，再把客户关心的功

能转成代表验收用例。

在线演示便于理解产品，不是达梦、openGauss 或金仓的现场证据。最终数据库选择，应以指定环境

组合的结果与项目要求相匹配。

常见问题（FAQ）

达梦、openGauss 与人大金仓，哪一个适配证据更完整？

在本文引用的实验基线中，达梦已有用印审批闭环；openGauss 验证至填报；人大金仓具有框架接入

能力，本轮未取得实库验收。

有 PostgreSQL 验证结果，能否省略金仓现场测试？

不能。协议与方言相近不代表指定版本、驱动、认证和全部业务行为相同。对照结果可以帮助定位差

异，不能代替目标实库。

登录和审批通过，是否说明财务、ERP 也全部通过？

不说明。代表流程覆盖指定链路，其他模块仍需要选择实际查询、写入、导出与业务规则执行用例。

怎样避免采购与实施对"支持"理解不同？

把环境、用例、状态和证据一起写进验收条款。用"指定版本的用印审批闭环通过"替代没有范围的"

完全支持"。

结语：让选型结论可以进入验收合同

国产数据库选型的可靠依据，是目标环境、工程能力和代表业务证据之间的对应关系。

RuoYi Office 提供可复用的多库能力与实验资料，帮助采购方和实施团队把"支持"分解成可观察结

果。明确边界并不会削弱方案，反而让交付排期、风险和后续验证更加可控。

你们的国产化验收条款，会写到数据库版本、代表单据与结果回写吗？这些细节比单独列出数据库名

称更容易形成双方共同认可的结论。

系列阅读

• openEuler + 毕昇 JDK + Tengine：RuoYi Office 国产化部署实战
• SpringBoot3 + 达梦 DM8：RuoYi Office 用印申请与多级审批实战
• SpringBoot3 + openGauss：RuoYi Office 登录、流程发布与用印填报适配实战
• 达梦 DM8 + openGauss：RuoYi Office 的 MySQL 数据转换与导入实践
• openEuler + 达梦 DM8 + openGauss：RuoYi Office 多库部署与运行维护实践

如果这篇对你有用，点个「在看」或收藏。

🌐 演示地址 ：https://ruoyioffice.com/web

📦 GitHub 源码 ：https://github.com/yuqing2026/ruoyi-office

📦 Gitee 源码 ：https://gitee.com/yqzy1688/ruoyi-office

💬 微信：17156169080（获取产品咨询）

打开演示地址直接查看系统。