视图不能自动转换非结构化数据，关键在sql表达式：key-value用case when（非pivot），xml用.nodes()或xmltable（路径须精确），禁用json包装方案；源头key语义统一比技巧更重要。
不能靠视图“自动”转换非结构化数据——它只封装查询逻辑，真正起作用的是你写的 SQL 表达式。关键在选对模式：Key-Value 用 CASE WHEN 或 PIVOT，XML 用 .nodes() 或 XMLTABLE，别碰 JSON 包装方案。
Key-Value 表转固定列：用 CASE WHEN 而不是 PIVOT（兼容性优先）
多数生产环境不值得为 PIVOT 绑定数据库版本和硬编码列名。用条件聚合更稳、易调、好扩展。
-
GROUP BY record_id是必须的，漏掉会导致整张表被聚成一行 - 每个
CASE WHEN key = 'status' THEN value END返回一列，外层套MAX()是为了把该record_id下唯一匹配值“提”出来；没匹配就是NULL - 如果
value存的是数字但字段类型是TEXT，直接ORDER BY status会按字典序排——得显式转换：MAX(CASE WHEN key = 'status' THEN value::INTEGER END)（PostgreSQL）或CAST(MAX(CASE WHEN key = 'status' THEN value END) AS SIGNED)（MySQL） - 新增一个 key（比如
due_date），只需加一个CASE块，不影响已有逻辑
XML 字段摊开成行：路径错一个字符就静默丢数据
.nodes()（SQL Server）或 XMLTABLE（Oracle）不会报错，只会跳过整行——这是最常被忽略的坑。
- 确保 XML 字段非
NULL且格式良构：SQL Server 加WHERE xml_col IS NOT NULL AND xml_col.exist('/root') = 1；Oracle 在XMLTABLE的PASSING子句里必须绑定命名空间，哪怕只是默认xmlns="http://xxx" - 路径必须精确匹配大小写和层级：实际是
<items><item></item></items>，却写/root/Item→ 全部丢失；应写/Items/Item或补全前缀 - 提取文本节点必须写
text()：Oracle 中PATH 'USER_DEAL_ID/text()'才得纯字符串，否则可能返回带标签的 XML 片段 - 日期类字段建议先用字符串类型提取，再用
TO_DATE()或::DATE转换，避免格式不一致直接报错（如 ORA-01843）
别用 JSON 函数“假装结构化”
把 Key-Value 塞进 JSON_OBJECT_AGG(key, value) 再用 ->>'status' 提取，看似灵活，实则让查询退化。
-
WHERE data->>'status' = 'active'无法走索引，哪怕给data建了 GIN 索引，也是全表扫描 - 拿 JSON 字段和其他表
JOIN，等于每次 JOIN 前都得解析一遍 JSON，CPU 和内存压力陡增 - 这种写法只适合下游应用能自己解析 JSON、且读多写少的场景，不适合 BI 或高频查询
最易被忽略的一点：视图不改物理结构，也不解决数据语义混乱。如果原始 key 名不统一（比如一会儿叫 stat，一会儿叫 status），再强的 SQL 也转不出规范列——源头统一 key 语义，比任何视图技巧都重要。
