SQL视图规范化依赖人为约定与工具评审而非语法强制，须用CREATE OR REPLACE VIEW原子更新、显式schema、禁用SELECT*、列名小写下划线、布尔字段加is_前缀、过滤逻辑移至CTE、视图名带vw_前缀及业务域标识。
SQL 视图本身不支持注释块、缩进控制或参数化，所谓“规范化”本质是人为约定 + 工具辅助 + 评审卡点——没有语法强制力，靠的是团队对 CREATE VIEW 语句结构和命名的持续共识。
视图定义必须用 CREATE OR REPLACE VIEW 开头
避免先 DROP VIEW 再 CREATE VIEW：前者在并发场景下可能被其他会话引用失败，后者能原子更新。PostgreSQL / Oracle / SQL Server 均支持 OR REPLACE（MySQL 8.0.19+ 也支持），但注意：OR REPLACE 不会修改已有权限，需手动 GRANT。
- 始终显式声明 schema，例如
CREATE OR REPLACE VIEW sales.vw_monthly_summary AS，不写vw_monthly_summary - 若数据库不支持
OR REPLACE（如旧版 MySQL），改用CREATE VIEW IF NOT EXISTS+ 手动比对定义变更 - 禁止在视图体中写
SELECT *，列名必须显式列出，否则上游表加字段会导致视图逻辑意外变化
列别名统一用下划线分隔 + 小写字母
视图输出列名是外部调用的接口，命名需自解释且与底层表解耦。比如源表有 customer_name 和 CUSTOMERNAME 混用，视图中应统一为 customer_name，而非沿用原始大小写或驼峰。
- 禁止使用空格、中文、特殊符号（如
@、#）作列别名；必须用双引号包裹才生效，但会增加下游引用成本 - 数字后缀用
_v2而非_2，例如order_amount_v2，便于排序和识别版本演进 - 布尔类字段统一加
is_前缀，如is_active、is_deleted，不写active_flag或deleted_ind
WHERE 条件必须提取到 CTE 或子查询中，主 SELECT 只做投影
把过滤逻辑塞进最外层 WHERE 容易掩盖业务含义，也妨碍复用。用 CTE 显式命名意图，例如 active_orders、recent_customers，让视图结构一眼可读。
CREATE OR REPLACE VIEW sales.vw_top_customers_by_revenue AS WITH active_orders AS ( SELECT * FROM sales.orders WHERE status = 'completed' ), customer_revenue AS ( SELECT customer_id, SUM(amount) AS total_revenue FROM active_orders GROUP BY customer_id ) SELECT c.customer_id, c.customer_name, cr.total_revenue FROM customer_revenue cr JOIN sales.customers c ON cr.customer_id = c.id ORDER BY cr.total_revenue DESC LIMIT 100;
- CTE 名称用名词短语，小写+下划线，不带
cte_前缀 - 主
SELECT中禁用计算列（如amount * 0.9），应封装进 CTE 或单独视图 - 所有 JOIN 必须写
ON条件，禁止逗号分隔的隐式 JOIN
视图名必须带前缀 vw_ 且反映业务域
前缀不是为了“区分类型”，而是降低认知负荷：开发查表时看到 vw_ 就知道不能 INSERT，DBA 清理对象时可快速过滤。更重要的是，它迫使你回答一个问题：“这个视图属于哪个业务边界？”
- 前缀后紧跟两段式命名：
vw_{domain}_{purpose}，例如vw_finance_daily_balance、vw_marketing_campaign_stats - 禁止出现
tmp_、test_、backup_等临时性前缀；视图一旦上线，就应视为稳定契约 - 跨 schema 视图不推荐，但如果必须存在（如
reporting.vw_sales_summary引用sales.orders），应在文档中标明依赖链
最难的部分不是写规则，而是让所有人每次 CREATE VIEW 时都多想两秒：这个名称会不会让三个月后的自己困惑？这个 CTE 是不是真的表达了“活跃订单”而不是“没取消也没完成的订单”？规范不在文档里，在每一次保存前的停顿中。
