SQL视图命名须强制采用teamname_businessarea_viewname_v1格式，如marketing_analytics_user_active_v2；禁止硬编码表名，字段注释须与共享字典单向同步，v2必须新建而非ALTER覆盖，版本差异需diff比对。
SQL视图命名必须带团队前缀和业务域后缀
跨团队共享视图最常踩的坑是名字冲突——两个团队都建了 user_profile，下游一用就错。命名不是风格问题，是契约问题。
- 强制格式：
teamname_businessarea_viewname_v1（如marketing_analytics_user_active_v2） - 前缀用小写英文缩写，避免用
dev、test这类泛化词，优先取团队在公司组织架构里的正式简称 - 版本号
v1必须显式写在最后，且只在语义不兼容变更时才升版（比如删字段、改类型），加字段不算 - 别依赖数据库 schema 隔离来“解决”重名——不同团队可能共用一个
sharedschema，schema 不是命名空间替代品
视图定义里禁止硬编码表名或库名
硬编码 prod_db.users 或 analytics_v3.fact_orders 会让视图在测试环境、多租户实例或数据迁移时直接失效。
- 所有底层表引用必须通过
CREATE VIEW ... AS SELECT ... FROM ${table_ref}的方式抽象，实际替换由部署工具或变量注入完成 - 若用 dbt，用
{{ ref('model_name') }}；若用 DataGrip + SQLFluff，配置templater: jinja并统一管理变量文件 - 特别注意：MySQL 不支持 CTE 引用变量，PostgreSQL 的
SET LOCAL也不能用于视图定义，这类限制必须提前验证 - 上线前跑一次
SELECT * FROM view_name LIMIT 0只能验语法，不能验路径有效性——得连到目标环境执行EXPLAIN看真实执行计划是否命中预期表
字段注释必须和共享字典保持单向同步
字典文档更新了，视图 COMMENT ON COLUMN 没跟上，下游就会按过期描述理解字段，这种偏差很难被自动化发现。
- 字典源唯一可信：只允许从 Confluence 表格或 YAML 文件生成 SQL 注释脚本，禁止人工维护两份
- 每次视图 DDL 提交前，CI 流水线必须运行校验命令：
sqlfluff parse view.sql --dialect postgres | grep -q "missing_comment"（需提前配置规则） - PostgreSQL 中用
COMMENT ON COLUMN，但注意它不支持中文引号、换行符，否则pg_dump会导出乱码；建议统一用 ASCII 单引号 + URL 编码空格 - 字段别名（
AS user_status）必须和字典中“逻辑名”完全一致，大小写敏感——BI 工具常直接映射该别名，拼错就查不到字段
ALTER VIEW 不能替代重建，v2 视图必须独立存在
有人想省事用 ALTER VIEW marketing_analytics_user_active_v1 AS ... 直接覆盖，结果导致所有依赖 v1 的报表突然行为改变，没人知道发生了什么。
-
ALTER VIEW在 PostgreSQL / MySQL 中仅修改定义，不触发依赖检查，也不留历史快照 - 正确做法：新建
marketing_analytics_user_active_v2，等所有下游确认切换后再归档v1（归档 ≠ DROP，而是加/* DEPRECATED: use v2 */注释并设权限为只读） - 版本间差异必须用
diff工具比对 DDL，重点看SELECT列顺序、NULLABLE 属性、聚合函数使用（如COUNT(*)改成COUNT(user_id)会影响语义） - 如果团队用 Airflow 调度，
v1和v2的调度 DAG 必须隔离，禁止共用同一个task_id—— 否则重试会混用版本
最麻烦的不是写视图，是让所有人相信“这个 v2 真的和字典描述一致”。每次发布前手动跑一遍字典字段清单 vs SELECT column_name, data_type FROM information_schema.columns 对比，比写十行注释都管用。
