像给两栋仓库里的货架贴标签：只写“员工表”，人能看懂所在楼层，管理系统却可能把它们当成同一个东西。一位正在用 Snowflake 和 dbt 重建数据仓库的工程师，就遇到了这个问题。数据先从业务系统进入 ODS——保存较贴近源头的数据副本——再加工到 EDW，也就是供全公司分析使用的企业数据仓库。
他的 ODS 里有 SOURCE1.EMPLOYEES 和 SOURCE2.EMPLOYEES，EDW 里还有 DIM.EMPLOYEES。理想的文件目录能用数据库和 schema 分层，但三个模型若都叫 employees，会重名；改成 source1_employees，又无法与 Snowflake 表名完全对应。他因此考虑，是让 dbt 模型名不同于实际表名，还是反过来调整数据库、schema 和表的结构。
这不只是命名洁癖。dbt 会把 SQL 转换按模型组织、测试和部署；模型名称与项目边界会进入数据血缘——一张表从哪里来、经过哪些转换的“家谱”——也会影响授权范围和发布方式。这个案例值得注意的地方，正是命名不能脱离跨库边界单独统一。原帖只提出了设计问题，未给出最终方案或实践结果。