doubao-seed-2-0-mini 在「Oracle到PostgreSQL递归语法转换」的评测结果

这是该 AI 模型在此测试用例上的详细评测结果。

基本信息

  • 模型名称：doubao-seed-2-0-mini
  • 用例名称：Oracle到PostgreSQL递归语法转换
  • 测试类型：文本生成
  • 评测维度：SQL 数据库能力

系统提示词（System Prompt）

这是给 AI 模型的背景设定和角色指令：

你是一名资深数据库工程师，精通Oracle和PostgreSQL两种数据库的SQL语法差异。 回答要求： 1. 给出完整的转换后SQL语句 2. 简要说明关键语法的对应关系 3. 确保转换后的SQL语法正确，可直接在PostgreSQL中执行

用户提示词（User Prompt）

这是用户给 AI 模型的具体任务要求：

请将以下Oracle递归查询转换为PostgreSQL的WITH RECURSIVE语法： ```sql SELECT employee_id, manager_id, name, LEVEL FROM employees START WITH manager_id IS NULL CONNECT BY PRIOR employee_id = manager_id; ``` 该查询的含义是：从根节点（没有上级的员工）出发，递归遍历整棵员工层级树，并返回每个节点的层级深度。 请给出等价的PostgreSQL写法，并说明主要语法对应关系。

任务要求

AI 模型需要满足以下要求：

  1. 正确使用WITH RECURSIVE定义递归CTE结构
  2. 正确设置递归初始条件（对应START WITH manager_id IS NULL）
  3. 正确编写递归关联条件（对应CONNECT BY PRIOR employee_id = manager_id）
  4. 正确实现LEVEL列的等价计算（使用depth或level字段递增）
  5. 说明Oracle与PostgreSQL关键语法的对应关系

评测结果

综合得分

该模型在此用例的得分为：95.3 分（满分 100 分），已通过

基础难度评测结果

  • 得分：95.3 分
  • 通过状态：已通过

模型生成产物

以下是该模型针对此任务的实际生成内容：

### 转换后的PostgreSQL完整SQL ```sql WITH RECURSIVE employee_hierarchy AS ( -- 锚成员：对应Oracle的START WITH子句，定义递归起始节点（无上级的根员工） SELECT employee_id, manager_id, name, 1 AS level FROM employees WHERE manager_id IS NULL UNION ALL -- 递归成员：对应Oracle的CONNECT BY逻辑，遍历子节点 SELECT e.employee_id, e.manager_id, e.name, eh.level + 1 AS level FROM employees e -- 关联条件等价于Oracle的CONNECT BY PRIOR employee_id = manager_id -- 即上一层节点的employee_id = 当前子节点的manager_id INNER JOIN employee_hierarchy eh ON e.manager_id = eh.employee_id ) SELECT employee_id, manager_id, name, level FROM employee_hierarchy; ``` --- ### 关键语法对应关系 | Oracle语法 | PostgreSQL等价语法 | 说明 | |---|---|---| |`START WITH manager_id IS NULL`| 递归CTE的锚查询（第一个不带UNION ALL的SELECT） | 定义递归的起始根节点 | |`CONNECT BY PRIOR employee_id = manager_id`| 递归成员的`INNER JOIN employee_hierarchy eh ON e.manager_id = eh.employee_id` | Oracle中`PRIOR`修饰的列代表**父节点字段**，此处等价于：子节点的`manager_id` = 父节点的`employee_id` | |`LEVEL`伪列| 手动维护的`level`计算列 | 根节点初始化为1，每递归一层层级+1，和Oracle的`LEVEL`伪列结果完全一致 | | 递归查询整体结构 |`WITH RECURSIVE ...`| PostgreSQL必须显式声明`RECURSIVE`关键字，Oracle的`CONNECT BY`是专用递归语法 |

AI 评审点评

以下是 AI 评审对该模型输出的点评：

【CLAUDE】候选输出整体质量优秀，SQL转换准确无误，语法完全正确，语义与原Oracle查询完全等价，语法对应关系说明清晰。与参考答案相比，缺少执行流程的详细说明、注意事项（循环引用防护、关键字冲突）以及ORDER BY排序，但这些均属于锦上添花的内容，不影响核心功能的正确性。是一份高质量的转换答案。 【GEMINI】模型表现出色，完美完成了从 Oracle 递归查询到 PostgreSQL WITH RECURSIVE 的转换任务。代码逻辑严谨，语法完全正确，且对关键语法差异的说明非常到位，展现了资深数据库工程师的专业水平。 【KIMI】候选输出是一份高质量的Oracle到PostgreSQL递归查询转换，核心语法转换准确，WITH RECURSIVE结构、锚点查询、递归JOIN条件以及LEVEL列的实现均正确无误。语法对应关系的说明清晰，特别是通过表格形式对比和PRIOR关键字的解释有助于理解。主要改进空间在于：补充递归执行流程的详细说明、增加关键字冲突和循环引用等注意事项、以及在最外层查询中添加ORDER BY以提升结果可读性。整体达到优秀水平，可直接用于生产环境。

进阶难度评测结果

  • 得分：81.2 分
  • 通过状态：已通过

模型生成产物

以下是该模型针对此任务的实际生成内容：

### 等价PostgreSQL SQL语句 ```sql WITH RECURSIVE emp_hierarchy AS ( -- 锚成员：对应Oracle的START WITH manager_id IS NULL SELECT employee_id, name, manager_id, 1 AS hierarchy_level, -- 对应Oracle的LEVEL（从1开始计数） '/' || name AS full_path, -- 等价SYS_CONNECT_BY_PATH(name, '/') name AS root_name, -- 初始根节点名称，后续递归继承 ARRAY[employee_id] AS visited_emp_ids, -- 记录已访问的员工ID，用于实现NOCYCLE ARRAY[name] AS sort_path -- 用于实现ORDER SIBLINGS BY的排序路径 FROM employees WHERE manager_id IS NULL UNION ALL -- 递归成员：对应Oracle的CONNECT BY PRIOR employee_id = manager_id SELECT e.employee_id, e.name, e.manager_id, cte.hierarchy_level + 1, cte.full_path || '/' || e.name AS full_path, cte.root_name, -- 始终继承根节点名称，等价CONNECT_BY_ROOT cte.visited_emp_ids || e.employee_id AS visited_emp_ids, -- 追加当前员工ID到已访问列表 cte.sort_path || ARRAY[e.name] AS sort_path FROM employees e INNER JOIN emp_hierarchy cte ON cte.employee_id = e.manager_id -- PRIOR employee_id = manager_id：父节点的employee_id等于当前子节点的manager_id WHERE -- 实现NOCYCLE：防止循环引用，跳过已访问过的员工ID NOT (e.employee_id = ANY(cte.visited_emp_ids)) ) -- 最终查询：对应Oracle的其余部分 SELECT employee_id, name, manager_id, hierarchy_level AS LEVEL, -- 重命名为Oracle的列名 full_path, root_name FROM emp_hierarchy -- 过滤层级<=3，对应Oracle的WHERE LEVEL <=3 WHERE hierarchy_level <= 3 -- 实现ORDER SIBLINGS BY name：按排序路径排序，同级节点按name升序 ORDER BY sort_path; ``` --- ### 各转换点详细说明 #### 1. `NOCYCLE` 的等价处理 - **Oracle行为**：`NOCYCLE`用于在出现循环引用（如A的上级是B，B的上级是A）时终止递归，避免抛出`ORA-01436`循环错误。 - **PostgreSQL实现**： 1. 在递归CTE中新增`visited_emp_ids`数组，记录从根节点到当前节点的所有唯一员工ID（锚成员初始化为`ARRAY[employee_id]`，递归成员追加当前员工ID）。 2. 在递归连接的WHERE条件中添加`NOT (e.employee_id = ANY(cte.visited_emp_ids))`，跳过已访问过的员工ID，避免循环递归。 - **推荐理由**：使用唯一的员工ID判断循环，避免了重名员工的干扰，比使用name更可靠。 --- #### 2. `SYS_CONNECT_BY_PATH(name, '/')` 的等价实现 - **Oracle行为**：生成从根节点到当前节点的路径，以`/`分隔`name`字段。 - **PostgreSQL实现**： 1. 锚成员中根节点的路径为`'/' || name`（如根节点A的路径为`/A`）。 2. 递归成员中每个子节点的路径为父节点路径拼接`'/' + 当前节点name`（如B的路径为`/A/B`）。 - **推荐理由**：直接通过字符串累积实现，和Oracle的函数行为完全一致，可读性强。 --- #### 3. `CONNECT_BY_ROOT name` 的等价实现 -...

AI 评审点评

以下是 AI 评审对该模型输出的点评：

【KIMI】该候选输出完成了基本的Oracle到PostgreSQL递归查询转换，核心逻辑（NOCYCLE检测、路径拼接、根节点传递）实现正确，但存在关键的数组构造语法错误（`ARRAY[e.name]`应为`e.name`），导致ORDER SIBLINGS BY语义不完全等价。此外，LEVEL过滤的优化策略与参考答案推荐存在偏差，且未提及PostgreSQL 14+的CYCLE子句作为现代替代方案。说明文档结构良好但缺乏对潜在陷阱的深入分析，整体属于中等偏上水平，可作为基础转换参考但需修正数组拼接错误后方可生产使用。

困难难度评测结果

  • 得分：49.5 分
  • 通过状态：未通过

模型生成产物

以下是该模型针对此任务的实际生成内容：

### 一、完整可执行的PostgreSQL等价SQL ```sql WITH RECURSIVE active_employees AS ( -- 预过滤活跃部门的员工，简化后续递归逻辑 SELECT e.employee_id, e.name, e.department_id, e.manager_id FROM employees e JOIN departments d ON e.department_id = d.department_id WHERE d.is_active = 1 ), employee_hierarchy AS ( -- 1. 初始化根节点：匹配Oracle的START WITH条件 SELECT ae.employee_id, ae.name, ae.department_id, (SELECT dept_name FROM departments WHERE department_id = ae.department_id) AS dept_name, 1 AS depth, ae.name AS full_path, ae.employee_id AS root_id, NULL::VARCHAR AS parent_name, -- 根节点无父节点 ARRAY[ae.name::TEXT, ae.employee_id::TEXT] AS sort_key, 'N'::VARCHAR AS is_cycle -- 用于检测循环引用 FROM active_employees ae WHERE ae.employee_id IN ( -- 等价Oracle MINUS的PostgreSQL EXCEPT写法，严格匹配原逻辑 SELECT manager_id FROM active_employees WHERE manager_id IS NOT NULL EXCEPT SELECT employee_id FROM active_employees WHERE manager_id IS NOT NULL ) UNION ALL -- 2. 递归遍历子节点，添加循环检测防止无限递归 SELECT curr_ae.employee_id, curr_ae.name, curr_ae.department_id, (SELECT dept_name FROM departments WHERE department_id = curr_ae.department_id) AS dept_name, parent.depth + 1 AS depth, parent.full_path || ' > ' || curr_ae.name AS full_path, parent.root_id, parent.name AS parent_name, -- 维护排序键，实现ORDER SIBLINGS BY的同级排序 parent.sort_key || ARRAY[curr_ae.name::TEXT, curr_ae.employee_id::TEXT] AS sort_key, -- 循环检测：如果当前节点已经在父路径中，则标记为循环 CASE WHEN parent.is_cycle = 'Y' OR curr_ae.employee_id = ANY(STRING_TO_ARRAY(parent.full_path, ' > ')::TEXT[]) THEN 'Y' ELSE 'N' END AS is_cycle FROM employee_hierarchy parent JOIN active_employees curr_ae ON curr_ae.manager_id = parent.employee_id WHERE parent.is_cycle = 'N' -- 跳过已检测到循环的分支 ), -- 3. 计算CONNECT_BY_ISLEAF：判断当前节点在结果集中是否有子节点 hierarchy_with_leaf AS ( SELECT eh.employee_id, eh.name, eh.department_id, eh.dept_name, eh.depth AS LEVEL, eh.full_path, eh.root_id, -- 严格匹配Oracle行为：仅统计当前结果集中的子节点 CASE WHEN EXISTS ( SELECT 1 FROM employee_hierarchy sub WHERE sub.manager_id = eh.employee_id AND sub.is_cycle = 'N' ) THEN 0 ELSE...

AI 评审点评

以下是 AI 评审对该模型输出的点评：

【KIMI】该候选输出在Oracle到PostgreSQL的递归查询迁移任务中存在严重问题。主要缺陷包括：(1) SQL语法错误多，多处引用不存在的列，实际无法执行；(2) 核心算法错误，特别是循环检测和同级排序的实现；(3) 语义等价性差，关键转换点（如先JOIN后递归 vs 先递归后JOIN、START WITH子查询的作用范围）未正确处理；(4) 分析深度不足，对难点问题的解释存在概念性错误。虽然整体结构完整，覆盖了所有要求的任务点，但具体实现质量远低于专业数据库迁移的标准。建议重新学习WITH RECURSIVE的标准写法，特别是path_ids数组用于循环检测、排序路径编码用于ORDER SIBLINGS BY、以及递归查询中JOIN顺序对语义的影响等核心知识点。

相关链接

您可以通过以下链接查看更多相关内容：

加载中...
100%