如何规范化SQL视图编写风格_统一代码布局与命名习惯-SQL-PHP中文网

SQL视图规范化依赖人为约定与工具评审而非语法强制，须用CREATE OR REPLACE VIEW原子更新、显式schema、禁用SELECT*、列名小写下划线、布尔字段加is_前缀、过滤逻辑移至CTE、视图名带vw_前缀及业务域标识。

如何规范化sql视图编写风格_统一代码布局与命名习惯

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），应在文档中标明依赖链