反范式字段需通过视图契约化映射为标准列，而非硬编码解析：显式声明字段、类型兜底、NULL容忍、版本意识，并用真实脏数据验证，否则易成维护黑洞。
能，但必须把反范式字段“翻译”成规范结构，不能直接 SELECT * 或裸露拼接逻辑。 视图本身不改数据，只改查询视角；老旧系统里常见的 full_address（含省市区邮编电话）、user_roles（逗号分隔字符串）、json_metadata（嵌套配置）这类字段，靠视图拆解后暴露为独立列，才能被新系统安全消费。
为什么不能直接在视图里用 SUBSTRING/JSON_EXTRACT 就完事
反范式字段的解析逻辑容易变成维护黑洞：一处改，处处崩。比如 full_address 在不同地区格式不一（有的带括号，有的用顿号），硬写在视图里会导致 SELECT 报错或返回空值；json_metadata 里字段名大小写不统一、键缺失、嵌套层级变化，都会让 JSON_EXTRACT 失效。
- MySQL 的
JSON_EXTRACT遇到不存在的 key 返回NULL，但 PostgreSQL 的->>默认报错，需包一层COALESCE((data->>'role')::TEXT, '') - 用
SUBSTRING_INDEX(full_address, ',', 1)取省名，在“北京市,朝阳区,建国路1号”里是对的，在“广东省深圳市南山区科技园”里就切错——没有通用分隔符 - 视图一旦定义了
JSON_EXTRACT(data, '$.config.timeout')，后续 JSON 结构微调（比如改成$.settings.timeout），所有调用方立刻中断
如何安全地把反范式字段“展开”为标准列
核心是：字段必须显式声明 + 类型兜底 + NULL 容忍 + 版本意识。不是“解析”，而是“契约化映射”。
- 对地址类字段，不试图全自动拆解，而是用固定字段兜底：
COALESCE(NULLIF(TRIM(SUBSTRING_INDEX(full_address, ',', 1)), ''), '未知省份') AS province - 对角色字符串（如
'admin,editor'），不塞进视图做FIND_IN_SET，而是暴露为布尔标记：IF(full_address LIKE '%admin%', 1, 0) AS is_admin（MySQL）或(string_to_array(user_roles, ',') @> ARRAY['admin']) AS is_admin（PostgreSQL） - 对 JSON 字段，只取确定存在的顶层键，且强制转类型：
CAST(data->>'status' AS INTEGER) AS status_code，避免隐式转换失败 - 所有字段加注释说明来源和假设，例如：
-- 来源: full_address, 假设首段为 province，无逗号时全作 province
哪些操作会让视图变成“纸糊的接口”
视图能稳住读请求，但掩盖不了底层设计缺陷。以下行为会快速暴露裂缝：
- 在视图里用
UNION ALL合并多个反范式表（如legacy_users_v1和legacy_users_v2），字段语义不一致时，is_active在 v1 是 TINYINT，在 v2 是 VARCHAR('Y'/'N')，视图里没CAST就直接SELECT，下游 ORM 解析失败 - 依赖数据库方言做复杂解析：SQL Server 的
STRING_SPLIT返回表值函数，不能直接放SELECT列表；MySQL 8.0+ 才支持，旧版直接报错 - 把视图当表授权写入：反范式字段通常对应多张物理表，
UPDATE v_user_profile SET full_address = '...' WHERE id = 1必然失败，因为视图不可更新 - 没配
SCHEMABINDING（SQL Server）或没跑pg_depend分析（PostgreSQL），底层表字段删了，视图还能创建成功，但首次查询就崩
最麻烦的不是字段拆不开，而是没人知道这个视图里写的 province 其实是猜的——它没真实数据支撑，只是一层脆弱的语义胶带。上线前必须用真实脏数据集跑一遍 SELECT * FROM v_legacy_user LIMIT 1000，而不是只测“理想格式”。
