Oracle OBJECT 类型是用户定义的复合数据结构，需用 CREATE TYPE 显式创建，不支持局部声明；PL/SQL 中须调用同名构造函数实例化；可用作表列或集合元素，但查询需显式点号访问字段，无法直接 JSON 化。
如何定义 Oracle OBJECT 类型（CREATE TYPE）
Oracle 的自定义 OBJECT 类型本质是用户定义的复合数据结构，类似其他语言里的 struct 或 class，但不包含方法体（仅声明接口）。必须用 CREATE TYPE 语句在数据库中显式创建，且需具备 CREATE TYPE 权限。
常见错误是直接在 PL/SQL 块里写 TYPE ... IS OBJECT —— 这在匿名块或包里不合法，Oracle 不支持局部 OBJECT 类型声明。
- 字段名不能是保留字，如
name、order，否则需加双引号（不推荐） - 支持嵌套：字段类型可以是另一个已存在的 OBJECT 类型、VARRAY、NESTED TABLE 或标量类型（
VARCHAR2、NUMBER等） - 不支持继承语法（如
UNDER）除非启用对象关系特性且有特殊授权 - 示例：
CREATE TYPE person_t AS OBJECT ( id NUMBER, name VARCHAR2(100), email VARCHAR2(255) );
如何在 PL/SQL 中声明并实例化 OBJECT 变量
OBJECT 类型定义后，可在 PL/SQL 中像使用内置类型一样声明变量，但实例化必须调用其默认构造函数 —— 函数名与类型名完全一致，参数顺序严格对应字段声明顺序。
容易踩的坑：漏传参数、参数类型不匹配、或误以为能用 := NULL 直接赋值（这只会让变量为 NULL，不是“空实例”）。
- 构造函数调用必须带括号，即使无字段（空 OBJECT 也需
my_obj := my_type()） - 字段为
NOT NULL时，构造函数不会校验，NULL 值仍可传入（约束只在表列上生效） - 若 OBJECT 含 VARRAY 或 NESTED TABLE 字段，其元素需用对应构造函数初始化（如
phone_list_t('123','456')） - 示例：
DECLARE p person_t; BEGIN p := person_t(101, 'Alice', 'alice@example.com'); DBMS_OUTPUT.PUT_LINE(p.name); -- 输出 Alice END;
如何将 OBJECT 用作表列或集合元素
OBJECT 类型最常见用途是作为表的列类型，或作为 VARRAY/NESTED TABLE 的元素类型。此时插入数据也依赖构造函数，不能用 JSON 风格字面量或匿名记录语法。
注意：用 OBJECT 列建表后，查询返回的是对象实例，不是展开的字段；想取字段得用点号访问（t.col_name.id），且该写法在 SQL 层受限（如不能在索引表达式中直接用 col.name）。
- 建表时 OBJECT 列不支持
DEFAULT子句（除非是空构造，如DEFAULT person_t(NULL,NULL,NULL)） - 若用于 NESTED TABLE，需先
CREATE TYPE对应的表类型（CREATE TYPE person_table_t AS TABLE OF person_t） - 插入示例：
CREATE TABLE employees (emp_data person_t); INSERT INTO employees VALUES (person_t(202, 'Bob', 'bob@example.com'));
为什么 SELECT 返回的对象无法直接 JSON 化或导出为字段列表
Oracle SQL 层把 OBJECT 当作原子值处理。即使你 SELECT emp_data FROM employees，结果集里这一列的类型仍是 person_t，客户端（如 SQL*Plus、JDBC）通常只显示 person_t 字符串，而非内部字段。
这不是 bug，而是设计使然：OBJECT 是强类型封装，打破封装需显式投影。
- 要展开字段，必须写
SELECT e.emp_data.id, e.emp_data.name FROM employees e - 想转成 JSON？Oracle 21c+ 支持
JSON_OBJECT(e.emp_data.id, e.emp_data.name)，但前提是字段逐个提取，不能传整个 OBJECT 实例进去 - PL/SQL 中可用
DBMS_JSON.OBJECT_TO_JSON（需 21c+）或手动拼接，但无通用反射机制 - 导出工具（如 Data Pump、SQL Developer）默认不展开 OBJECT 列，需额外配置或改写查询
实际用的时候，多数团队发现 OBJECT 类型的维护成本高于收益 —— 尤其当应用层已有成熟序列化逻辑时。真正需要它的场景其实很窄：比如对接遗留系统要求强类型 UDT、或构建复杂地理空间结构。别为了“面向对象”而强行套用。
