视图不能改变数据物理结构或规范化原始表，其规范性取决于SQL逻辑：用PIVOT（需硬编码列名、强制聚合）或CASE WHEN+GROUP BY（兼容性强、易扩展）将Key-Value转为固定列；避免JSON方案因索引失效和JOIN低效；关键在源头统一key语义。
视图本身不改变数据的物理结构，也不能“规范化”原始表——它只是封装查询逻辑。真正起作用的是你在视图定义里写的 SQL：用 PIVOT、CASE WHEN 或 JOIN 把非结构化 Key-Value 表转成固定列，这才是让展示逻辑变规范的核心。
用 PIVOT 写静态列视图（SQL Server / Oracle）
当你明确知道所有 key 名（比如只有 status、priority、category），且不希望每次加新 key 都改应用代码，PIVOT 是最干净的选择。但它要求你把每个目标列名硬编码进视图定义里。
-
PIVOT必须配合聚合函数（MAX(value)或MIN(value)），哪怕每record_id+key组只有一行——这是语法强制，不是可选 - 缺失某个 key 的记录，对应列值是
NULL，不是空字符串；如果业务需要默认值，得在外层用ISNULL([status], 'unknown') - SQL Server 中
IN ([status], [priority])里的方括号是必需的，Oracle 则要用双引号：IN ("status", "priority") - 一旦新增一个 key（比如
due_date），视图就得重写并重新部署，不能自动识别
用 CASE WHEN + GROUP BY 替代 PIVOT（MySQL / PostgreSQL / 兼容优先）
绝大多数生产环境更倾向用条件聚合，因为不依赖数据库版本特性，逻辑透明，也方便加类型转换或默认值处理。
- 必须写
GROUP BY record_id，否则整张表会被聚合成一行 - 每个
CASE WHEN key = 'xxx' THEN value END返回一列，MAX()只是把该 record_id 下匹配到的非 NULL 值“捞出来”，没匹配则为 NULL - 如果
value实际存的是数字但字段类型是TEXT，直接ORDER BY status会按字典序排，得显式转换：MAX(CASE WHEN key = 'status' THEN value::INTEGER END)（PostgreSQL）或CAST(... AS SIGNED)（MySQL） - 这种写法天然支持部分 key 缺失，无需额外处理；加新列只需加一个
CASE块，不影响已有逻辑
别用 JSON 函数“绕开”列定义（PostgreSQL / MySQL）
有人把 Key-Value 直接塞进 JSON_OBJECT_AGG(key, value)，再用 ->>'status' 提取——这看似灵活，实则牺牲了关键能力。
- WHERE 条件无法走索引：
WHERE data->>'status' = 'active'会全表扫描，哪怕你给data字段建了 GIN 索引，性能也远不如原生列 - JOIN 效率低：拿 JSON 字段和其他表关联，基本等于在 JOIN 前先解析一遍 JSON，CPU 和内存压力都大
- 下游 BI 工具或 ORM 往往不识别 JSON 路径表达式，还得额外写解析逻辑，反而增加维护成本
- 只适合极少数场景：比如 key 名完全不可枚举、且查询几乎全是全量读取+客户端解析
真正容易被忽略的点是：视图的“规范性”不来自语法糖，而来自你是否提前约定好 key 的语义和取值范围。如果 key 表里混着 status、STATUS、order_status 这类变体，再漂亮的 PIVOT 视图也会漏数据——清洗和约束得在源头做，视图只是最后那层确定性的投影。
