视图不是分层工具，而是分层的载体；它仅固化已设计好的分层逻辑，真正决定分层是否成立的是字段来源、JOIN范围、计算粒度和业务语义，如明细层（DWD）映射基表、宽表层（DWM）禁止嵌套引用、应用层（DWS）不带WHERE过滤，且嵌套超两层易导致依赖失控、血缘断裂与性能退化。
视图不是分层工具，而是分层的载体
SQL 视图本身不实现分层，它只是把已设计好的分层逻辑固化为可复用、可授权、可演进的查询接口。真正决定分层是否成立的，是视图背后的字段来源、JOIN 范围、计算粒度和业务语义——比如 ord_fact_enriched_view 必须明确只整合订单事实 + 客户/商品维度基础属性，不能掺杂报表指标（如“近7日复购率”），否则就模糊了明细层与聚合层边界。
三层结构在视图体系中怎么落地
典型分层对应关系如下：
-
明细层（DWD）：直接映射基表或轻度清洗，字段名与源系统一致，不做聚合，命名如
ord_raw_view、mem_profile_view -
宽表层（DWM）：跨域 JOIN + 基础衍生字段（如
COALESCE(status, 'unknown')），禁止嵌套视图引用，命名如ord_customer_enriched_view -
应用层（DWS）：按报表/场景裁剪字段、做轻量聚合（SUM/COUNT），但不带 WHERE 过滤，命名如
ord_daily_summary_view
注意：没有“汇总层”视图能直接替代 BI 工具里的参数化筛选——所有 WHERE 条件必须由上层 SQL 或 BI 查询动态注入，否则会破坏复用性。
为什么嵌套超过两层就失控
视图嵌套不是代码复用，而是隐式依赖叠加。一旦出现 view_a → view_b → view_c → orders 链路：
- 修改
view_c的SELECT字段，view_a查询可能突然报错“column not found” - PostgreSQL 会内联展开，但 MySQL 8.0 默认物化中间结果，
EXPLAIN看不到真实执行路径 - BI 工具无法下推过滤条件到最底层，导致全量扫描
orders表再逐层过滤 - 字段血缘断裂：你查不到
view_a.order_amount最终来自哪个基表字段
守住两层上限，即“基表 → 宽表视图”，其余逻辑用 CTE 或上层 SQL 实现，才是可控的分层。
NULL 和类型不一致是分层崩塌的隐形导火索
跨库同步或下游应用消费时，视图里没显式处理 NULL，后果比想象中严重：
-
price * tax_rate中任一字段为 NULL，整行结果变 NULL，且不同数据库对 NULL * 数字的处理不一致（MySQL 返回 NULL，Oracle 可能报错） - 源表
amount是 DECIMAL(10,2)，视图里用CAST(amount AS INT)再 JOIN，可能因精度丢失导致关联失败 - 没加
COALESCE(status, 'unknown')::VARCHAR，下游 Python pandas 读取时字段类型自动变成 object，后续 GROUP BY 效率暴跌
所有字段在宽表层视图中必须完成类型对齐与 NULL 显式兜底，这不是“稳妥写法”，而是分层契约的底线。
