视图名和表名不可重复，需统一加前缀（如v_）、体现schema上下文、仅用小写字母数字下划线且长度≤32，避免特殊字符及关键字冲突，并在ci中正则校验。
视图名和表名撞了怎么办
SQL里视图和表共享同一命名空间，CREATE VIEW users 会直接报错，如果已有 users 表。这不是语法错误，而是数据库的硬性限制——PostgreSQL、MySQL 8.0+、SQL Server 都如此，Oracle 稍特殊但同样不允许同名对象共存。
常见错误现象：ERROR: relation "xxx" already exists 或 There is already an object named 'xxx' in the database。别急着删表或改视图逻辑，先看命名是否可收敛。
- 统一加前缀，比如所有视图用
v_（v_user_active）、物化视图用mv_、临时分析视图用an_ - 避免用业务实体名直接作视图名，
order比orders更危险（还可能撞关键字） - 团队内同步命名词典，比如「统计类视图必须含
_stat，权限相关必须含_acl」
不同环境视图名重复导致部署失败
开发库建了 v_report_monthly，测试库也建同名视图，但定义不同——上线时 CREATE OR REPLACE VIEW 看似能覆盖，实则埋雷：若目标库已存在同名但结构不兼容的视图，某些数据库（如 PostgreSQL）会拒绝替换，报 cannot change column type from xxx to yyy。
根本原因不是名字冲突，而是元数据不一致。部署脚本不能只靠 CREATE OR REPLACE 躺平。
- CI/CD 中执行视图变更前，先查
pg_views（PostgreSQL）或INFORMATION_SCHEMA.VIEWS（MySQL/SQL Server），比对定义哈希值 - 生产环境禁止直接
CREATE OR REPLACE，改用「删旧建新」流程，并加事务包装（注意：SQL Server 不支持视图 DROP/CREATE 在事务中） - 把视图 DDL 放进版本库时，文件名强制绑定版本号，如
v_sales_summary_v2.sql，避免覆盖误判
跨 schema 视图命名没隔离清楚
以为用了 schema_a.v_user 和 schema_b.v_user 就万事大吉？错。很多 ORM（如 Django、SQLAlchemy）默认不带 schema 前缀查视图，或迁移工具（Flyway/Liquibase）按名称匹配资源，仍会混淆。
更麻烦的是权限控制：给 schema_a 授权了 v_user，结果应用连到 schema_b 却查出空结果，排查时才发现是 schema 切错了，但名字一模一样，日志里根本看不出差别。
- 视图名必须体现 schema 上下文，例如
v_user_auth（auth schema）、v_user_profile（profile schema），而非都叫v_user - 在数据库连接层显式设置
search_path（PostgreSQL）或default_schema（SQL Server），不依赖对象名推导位置 - 禁止在视图定义里用裸表名跨 schema 查询，写死
schema_b.users而非users，否则迁移时容易漏掉依赖
视图名含特殊字符或大小写引发兼容问题
CREATE VIEW "User-Report-2024" 在 PostgreSQL 里合法，但在 MySQL（默认配置）或多数 BI 工具里直接解析失败；CREATE VIEW UserReport 在 SQL Server 不区分大小写，但连到 PostgreSQL 时可能被转成小写 userreport，再跟其他系统对接就错位。
这不是风格问题，是工具链断裂点。越靠近下游（报表、ETL、API 层），对名称的容忍度越低。
- 视图名只用小写字母、数字、下划线，开头必须是字母，长度不超过 32 字符（避开 Oracle 30 限制和 Snowflake 256 但实际建议更短）
- 绝对不用连字符、空格、中文、$、# 等符号，哪怕数据库支持，下游工具大概率不认
- 在 CI 流程里加校验脚本，用正则
^[a-z][a-z0-9_]{2,31}$扫描所有.sql文件中的CREATE VIEW后第一个标识符
命名不是贴标签，是给机器读的协议。一个视图名要同时满足数据库解析器、迁移工具、ORM 映射器、BI 连接器的语法要求——留余量比求个性重要得多。
