schema_name.view_name是唯一可靠解法：SQL标准允许视图与表同名，但查询默认匹配表；跨模式引用必须显式限定模式名，否则易因search_path变化或权限限制导致运行时错误。
视图名和表名冲突时，schema_name.view_name 是唯一可靠解法
SQL里允许视图和表同名，但查询时数据库默认只认表——哪怕你刚建了同名视图，SELECT * FROM my_table 仍会查表，不会自动切到视图。这不是bug，是标准行为。想明确调用视图，必须加模式名限定。
- PostgreSQL、SQL Server、Oracle 都严格区分
public.my_table（表）和public.my_table（视图），靠模式+名字组合唯一标识对象 - MySQL 例外：它没有真正的 schema 概念（database ≈ schema），所以
db_name.view_name可用，但同库内仍不能重名——建同名视图会直接报错ERROR 1050 (42S01): Table 'xxx' already exists - 别依赖搜索路径（如 PostgreSQL 的
search_path）来“默认选中”某个模式下的视图，路径顺序一变，行为就不可控
跨模式引用视图必须显式写全 schema_name.view_name
视图定义里如果引用了其他模式的表或视图，不加模式名，创建会成功，但后续执行可能失败——因为运行时解析依赖当前用户的 search_path 或默认 schema，不是定义时的上下文。
- 安全写法：在
CREATE VIEW的SELECT里，所有非当前模式的对象都带上模式名，比如SELECT id FROM sales.orders而不是SELECT id FROM orders - 否则容易遇到运行时报错：
ERROR: relation "orders" does not exist，尤其当视图被另一个 schema 下的函数调用时 - 视图本身的名字也建议带模式创建：
CREATE VIEW reporting.active_users AS ...，避免后续DROP VIEW active_users意外删掉别的 schema 下的同名视图
pg_views 和 sys.views 这类系统表能帮你快速定位冲突源头
光看 psql \dv 或 SSMS 对象资源管理器，容易漏掉同名不同模式的对象。得查系统视图才能确认全局命名情况。
- PostgreSQL：查
SELECT schemaname, viewname FROM pg_views WHERE viewname = 'my_view'，一次看到所有同名视图分布在哪些 schema - SQL Server：用
SELECT schema_id, name FROM sys.views WHERE name = 'my_view'，再关联sys.schemas拿 schema 名 - 别只查
INFORMATION_SCHEMA.VIEWS，它不保证返回所有 schema（尤其有权限限制时），pg_views/sys.views更直接可靠
应用代码里硬编码 schema.view 比依赖默认 schema 更稳定
ORM 或脚本里写 SELECT * FROM user_summary 看似简洁，但一旦 DBA 把视图移到 analytics schema，或应用连接用户默认 schema 改成 app，查询立刻失效。
- 所有生产 SQL 中的视图引用，统一写成
analytics.user_summary这种带 schema 的形式 - 配置化 schema 名也可以，但别让“默认 schema”成为隐含前提；环境间 schema 不一致（如 dev 用
public，prod 用prod）时，靠变量替换比改 SQL 更安全 - 注意：MySQL 用户要换用
database_name.view_name，语法一样，语义上 database 就是 schema
实际维护中，最麻烦的不是建视图那一刻，而是半年后有人在另一个 schema 里建了同名视图，而没人记得通知所有下游应用——这时候全靠日志里那条 relation "xxx" does not exist 和系统表里的残留记录对得上号。
