Oracle无内置JSON CRUD生成器，需基于ALL_TAB_COLUMNS等元数据视图+动态SQL手动拼装存储过程，核心是“用PL/SQL生成PL/SQL”，须校验标识符、处理BYTE/CHAR语义、正确识别复合主键，并手动验证WHERE条件、日期转换及LOB列处理。
Oracle没有内置的JSON CRUD生成器，得靠元数据+动态SQL拼装
Oracle本身不提供类似 SQL Server 的 codegen 架构或 FOR JSON 原生支持，也没有系统级函数能一键生成存储过程。所有“自动”都建立在手动解析 ALL_TAB_COLUMNS、ALL_CONSTRAINTS、ALL_CONS_COLUMNS 这些视图的基础上，再用 DBMS_OUTPUT.PUT_LINE 或临时表拼出可执行的 CREATE PROCEDURE 脚本。
这意味着：你写的不是“运行时逻辑”，而是“生成另一段 PL/SQL 的 PL/SQL”。容易踩的坑包括：
- 直接拼接列名/类型时未用
DBMS_ASSERT.SIMPLE_SQL_NAME校验，导致注入风险 - 忽略
VARCHAR2的BYTEvsCHAR语义，生成的参数长度错位（如VARCHAR2(10 BYTE)实际存不下 10 个中文） - 主键识别只查
PRIMARY KEY约束，漏掉复合主键中非首列的顺序，导致WHERE条件拼错
用 PL/SQL 动态构建 INSERT/UPDATE/DELETE 过程的核心套路
核心是把表结构读成记录集，逐列生成参数声明 + 绑定变量 + SQL 片段。以 INSERT 为例：
- 先查
ALL_TAB_COLUMNS获取非虚拟、非只读列（排除GENERATED ALWAYS AS列） - 对每列：
- 类型映射：把
NUMBER→NUMBER，VARCHAR2(50 BYTE)→VARCHAR2(50)（注意去掉BYTE后缀，否则编译报错） - 可空性判断：不可空列在过程参数里不加
:= NULL默认值 - 主键列跳过
INSERT的VALUES部分（除非是代理键且需显式插入）
- 类型映射：把
示例片段（生成参数行）：
DBMS_OUTPUT.PUT_LINE('p_' || col.column_name || ' IN ' ||
REGEXP_REPLACE(col.data_type || '(' ||
CASE WHEN col.data_precision IS NOT NULL THEN col.data_precision ||
CASE WHEN col.data_scale IS NOT NULL THEN ',' || col.data_scale END
WHEN col.char_length > 0 THEN col.char_length END || ')',
'BYTE\)|CHAR\)', ')') || ',');关键点：
-
REGEXP_REPLACE是为了清理BYTE/CHAR后缀，Oracle 存储过程参数不认这个修饰 -
data_scale仅对NUMBER有效，VARCHAR2只看char_length - 所有列名必须用
DBMS_ASSERT.SIMPLE_SQL_NAME(col.column_name)包一层，防特殊字符
为什么不能直接用 OPENJSON 或 JSON_TABLE 替代手写解析逻辑
Oracle 12c 起支持 JSON_TABLE，19c 支持 JSON_OBJECT，但它们解决的是「运行时解析 JSON 输入」的问题，不是「生成存储过程」的问题。你想让生成器支持 JSON 输入，就得在生成出的存储过程中硬编码：
-
JSON_TABLE的COLUMNS子句（列名、路径、类型必须和目标表严格对齐） - 每列的
ERROR ON ERROR NULL ON EMPTY策略要按可空性区分 - 主键列若来自 JSON，还得额外做
EXISTS检查，否则MERGE会失败
这反而增加了生成器复杂度。更实际的做法是：生成器只产出标准 SQL 绑定变量版过程，JSON 解析逻辑由上层应用或另一个包装函数完成——这样生成器职责单一，也避免把 Oracle 版本兼容性（如 12c vs 19c 的 JSON 函数差异）塞进模板。
生成后的存储过程必须手动验证的三个地方
自动生成只是起点，以下三处不检查，上线后必出问题：
-
WHERE条件是否覆盖全部主键列（尤其复合主键，顺序错或漏列会导致全表更新） -
DATE和TIMESTAMP列是否用了TO_DATE/TO_TIMESTAMP显式转换，还是直接绑定了字符串（隐式转换依赖NLS_DATE_FORMAT，环境一换就失效） -
LOB列（CLOB/BLOB）是否被跳过处理，或错误生成为IN VARCHAR2参数（会截断）
最省事的验证方式：用生成的存储过程脚本，在测试表上 EXEC 一个最小 JSON 示例，再查 USER_ERRORS 看有没有编译警告；接着用 DBMS_PROFILER 跑一次，确认绑定变量数量与声明完全一致。
真正麻烦的从来不是“怎么生成”，而是“怎么确保生成的代码在各种边缘表结构下不出错”——比如带双引号标识符的列名、含美元符的虚拟列、分区表的局部索引列。这些细节不会出现在教程里，但会在你第一次给客户表生成时突然报错。
