应统一使用 vw_ 前缀、业务域缩写紧随其后、添加类型后缀（如 _filtered/_agg/_stg），禁止嵌入时间粒度，以兼顾人工可读性与机器识别。
因为视图不是表，但常被当表用；没有明确前缀或后缀，查到一半才发现是视图，容易误判数据新鲜度、权限范围和物理存储方式。
vw_ 前缀比 v_ 更可靠
很多团队早期用 v_（如 v_user），结果跟临时表 t_user、备份表 b_user 混在一起，SQL 自动补全时根本分不清。而 vw_ 是业界更通用的信号——PostgreSQL 社区、Snowflake 官方示例、阿里云 DataWorks 模板都默认用它，工具链（如 dbt、DataGrip）也认这个约定。
实操建议：
- 统一用
vw_开头，比如vw_usr_active_users，不写v_active_users - 旧系统若已用
v_，迁移时不强制重命名，但新视图必须用vw_ - 禁止混用：同一项目里不能既有
v_order_summary又有vw_order_summary
业务域前缀必须紧贴 vw_，不能省略
只写 vw_monthly_sales 看似简洁，但没人知道这“sales”是指销售域、售前线索、还是财务回款。三个月后你查日志发现它被下游报表、风控模型、BI 看板同时引用，却无法快速判断影响面。
实操建议：
- 业务域缩写放
vw_后面，如vw_ord_monthly_summary（订单域）、vw_fnc_daily_balance（财务域） - 缩写需团队共识并文档化，避免
sal_和sales_并存 - 跨域视图（如订单+用户联合分析）用主责域前缀，辅以
_join标识，如vw_ord_usr_order_user_join
类型标识后缀决定下游怎么用它
没有后缀的视图，调用方只能靠猜：这个 vw_usr_profile 是带权限过滤的？还是含脱敏逻辑的？抑或只是原始字段映射？一旦猜错，轻则查不到数据，重则越权访问。
常见类型后缀及使用场景：
-
_filtered：含行级权限或状态过滤，如vw_usr_user_active_filtered—— 下游可直接用于前端列表，但不能用于对账 -
_agg：含 GROUP BY 或窗口函数，如vw_ord_order_daily_agg—— 下游禁止再 COUNT(*)，否则重复聚合 -
_stg：ETL 中间态，仅限内部调度用，如vw_fnc_stg_revenue_raw—— BI 工具里应设为隐藏 - 无后缀 = 风险信号：除非是极简投影（如仅重命名字段），否则一律补后缀
为什么不能把时间粒度塞进视图名？
像 vw_ord_order_monthly_2024 这种命名，下个月就得新建一个 _2025，下游代码要跟着改 WHERE，调度任务要复制粘贴，还容易漏掉某处引用。更糟的是，它暗示“这个视图只服务某个月”，掩盖了视图本该具备的时间参数化能力。
正确做法是让视图本身保持时间中立：
- 视图定义里不要写
WHERE order_date >= '2024-01-01'，改用 CTE 或参数占位（如WHERE order_date >= {{start_date}}，由调用方传入） - 真正需要固定时间点的场景（如月报快照），用物化表（
mat_ord_monthly_snapshot_202401）代替视图 - 如果数据库不支持参数化（如 MySQL 5.7），至少把时间条件抽到最外层，方便下游覆写
最易被忽略的一点：视图名里的业务域和类型标识，是给“人”看的第一道过滤器；而是否带 vw_，是给“机器”（IDE、CI 工具、血缘分析系统）识别的关键标记——少一个，自动化就断一环。
