该封装，而且推荐封装——只要维度转换在多个报表中重复出现，如将order_date拆为cal_year_month、fiscal_quarter等稳定逻辑，应沉淀进视图以保障一致性、可维护性与跨库兼容性；需用确定性函数（如to_char、format）、语义化命名，并避免耦合动态业务规则。
视图该不该封装 DATE_FORMAT 或 YEAR/MONTH 提取逻辑
该封装，而且推荐封装——只要这个维度转换在多个报表中重复出现。比如把 order_date 拆成 cal_year_month、fiscal_quarter 这类字段，属于稳定维度逻辑，适合沉淀进视图。
常见错误现象：每个报表都自己写 DATE_FORMAT(order_date, '%Y-%m')，结果某天财务要求财年从 4 月起算，得改 12 个地方；或者 MySQL 升级后 DATE_FORMAT 对 NULL 的处理变了，所有报表一起崩。
- 用确定性函数封装：PostgreSQL 用
TO_CHAR(order_date, 'YYYY-MM')，SQL Server 用FORMAT(order_date, 'yyyy-MM')，避免跨库迁移时出问题 - 字段名带语义，比如叫
cal_year_month而不是ym，后续 BI 工具拖拽时不会猜错 - 别在视图里写“动态财年偏移”，例如
YEAR(order_date) + (MONTH(order_date) >= 4)——它耦合业务规则，规则一变，视图就得重发版
地区、状态码这类映射字段该不该硬编码在视图里
可以用视图做静态码值映射，但必须满足前提：映射关系本身不常变。比如 status = 'S' → '已发货'、region_id = 101 → '华东'，这类业务字典完全可以固化在视图里。
容易踩的坑：
- 不能依赖数据库内置函数（如 MySQL 的
ELT）硬编码顺序 - 别用
CASE WHEN罗列全部可能值却漏掉新状态，这会导致NULL暴露给报表层，下游还得补ISNULL - 优先用
LEFT JOIN关联维表，比如JOIN dim_region r ON t.region_id = r.id，而不是在视图里写死CASE - 如果确实没维表（如临时项目），至少把
CASE封装成带注释的独立块，并加兜底ELSE '未知_' || status - 字段别名避开关键字，比如别叫
desc或order，否则在 SmartList Designer 或某些 BI 工具里会报语法错
视图里加 COALESCE(region, '未知地区') 是好习惯吗
是，而且强烈建议这么做。因为 NULL 在聚合、排序、BI 工具分组时行为不一致：Tableau 默认把 NULL 单独成一组，Power BI 可能直接过滤掉，而报表用户看到“少了一行数据”却找不到原因。视图层主动填充，等于统一了数据契约。
性能上几乎无损耗——COALESCE 是轻量计算，且现代数据库优化器基本能下推过滤条件；相比在每个报表 SQL 里补一次，它反而减少重复计算。
- 类型必须匹配：比如
COALESCE(region, 0)会触发隐式转换，MySQL 可能转成字符串'0'，导致后续WHERE region = '华东'失效 - 别对数值型字段填字符串兜底，比如
COALESCE(sales_amt, '0')，应写成COALESCE(sales_amt, 0) - 如果底层字段是
VARCHAR，兜底值也必须是字符串，且长度足够容纳拼接内容（如'未知_' || status）
聚合逻辑该不该写死在视图里
除非多个报表共享同一套分组逻辑，且该逻辑稳定不变，否则别把 GROUP BY 和 SUM() 写死在视图里。视图只做“宽表拼接”，聚合留到报表层更灵活。
问题出在：如果视图已含 GROUP BY 和 SUM()，而外层报表又加了 WHERE 过滤，某些数据库（如 MySQL 5.7）可能先算完聚合再过滤，而不是下推条件。
- 在 PostgreSQL 或 SQL Server 中，可对含聚合的视图建物化视图（
MATERIALIZED VIEW），但要注意刷新策略和锁影响 - 用
EXPLAIN对比视图调用前后执行计划，重点看rows和Filter是否出现在合适层级 - 分段预处理该拆成多个视图还是一个？取决于复用粒度和变更频率：一个大视图包揽所有清洗步骤，看似省事，但只要其中一步逻辑要改（比如补缺规则变），整个视图就得重测；而拆成
v_raw_orders→v_cleaned_orders→v_aggregated_orders，每层职责单一，上游改了不影响下游编译
EXPLAIN 输出里未必直观反映哪一层拖慢了整体。最容易被忽略的是：视图定义里的函数是否让索引失效，比如在 dm_order_detail 里对 order_time 做 DATE_FORMAT(order_time, '%Y-%m')，就会让 order_time 上的索引完全失效。
