视图命名须带业务前缀，如ord_daily_sales_view；禁止硬编码WHERE条件；嵌套不超过两层；NULL处理需显式类型转换；字段别名避开关键字；权限取决于创建者而非调用者。
视图命名必须带业务前缀，否则后期根本分不清谁在用
SQL 视图不是临时表，它一旦被多个报表、BI 工具甚至下游应用引用，就等同于接口契约。不加前缀的 user_summary 这种名字，在 20+ 个视图共存时，你根本不知道它是订单域的还是会员域的，更没法判断是否已被废弃。
实操建议：
- 统一用业务域缩写 + 下划线 + 功能描述，比如
ord_daily_sales_view（订单域）、mem_active_users_view（会员域） - 禁止使用
v_或view_这类无意义前缀，它们只增加噪音，不传递语义 - 如果视图仅用于某报表内部逻辑（且确定永不复用），可加
_local后缀，如fin_pnl_calc_local，团队需约定该后缀代表“不承诺稳定性”
WHERE 条件不能塞进视图定义里，那是调用者的责任
把过滤条件（比如 WHERE status = 'paid'）硬编码进视图，表面看省事，实际会锁死复用能力——下游想查全部状态？得另建一个视图；想按日期范围动态过滤？只能重写或套子查询，性能还变差。
常见错误现象：
- BI 工具拖拽字段时发现数据量远小于预期，查视图 DDL 才发现被静态过滤了
- 同一张事实表上建了
sales_today_view、sales_yesterday_view、sales_last7_view……本质只是 WHERE 不同，纯属冗余
正确做法是：视图只做字段裁剪、JOIN 整合、基础计算（如 amount * tax_rate），所有业务过滤交给上层 SQL 或 BI 的参数化查询。
嵌套视图超过两层，维护成本指数级上升
视图 A → 视图 B → 视图 C → 基表，这种链路看着模块化，实则一出问题根本没法快速定位：是 C 的字段别名错了？B 的 JOIN 条件漏了 NULL 处理？还是 A 的聚合逻辑和 B 冲突？EXPLAIN 也难读，因为各数据库对嵌套视图的执行计划展开程度不同。
性能与兼容性影响：
- PostgreSQL 会内联展开视图，但 MySQL 8.0 之前默认物化中间结果，嵌套越深，临时结果集越大
- 某些 BI 工具（如 Tableau）在解析多层嵌套视图时，可能无法正确推断字段血缘或下推过滤条件
- 只要任意一层视图结构变更（比如删字段），所有依赖它的上层视图都得人工验证，没有自动依赖检查
建议守住两层红线：基表 → 域宽表视图（如 ord_fact_enriched_view），再由报表 SQL 直接引用该宽表视图，必要时用 CTE 局部封装逻辑，不落地为视图。
NULL 处理和类型隐式转换必须显式声明，尤其跨库同步时
视图里写 COALESCE(price, 0) 看似稳妥，但如果源表 price 是 DECIMAL(10,2)，而你用 0（整型常量），某些数据库（如 Redshift）会把它转成 INT，导致整个表达式降级为整型，小数位丢失——报表里突然全是 99 元变成 99.00 元再变成 99，没人能立刻反应过来。
实操要点：
- 所有
COALESCE、CASE WHEN的返回分支，确保类型一致，显式 cast：COALESCE(price, 0.00::DECIMAL(10,2)) - 避免在视图里用
||拼字符串，不同数据库空值拼接行为不一致（PostgreSQL 返回 NULL，MySQL 返回空字符串），改用CONCAT()或明确判空 - 如果视图要被其他系统（如 Python pandas.read_sql）消费，字段别名尽量避开关键字，比如别叫
order、user，否则驱动报错还得查半天
最麻烦的其实是权限继承——视图能查到的数据，只取决于创建者权限，而不是调用者。这点容易被忽略，直到某天运营同学反馈“我明明有用户表权限，为什么查 mem_profile_view 报 permission denied”。
