视图是实现企业级通用数据维度字典最轻量、可控且可复用的载体，通过为各数据库定制底层视图（如SQL Server的v_db_dict_sqlserver），再用调度视图UNION ALL+字段对齐，统一拼接INFORMATION_SCHEMA、系统表及业务元数据等多源碎片信息，确保table_name等别名一致、column_comment设默认值，并避免在视图中硬编码WHERE过滤或运行时函数，最终形成职责分明、可联可查可权限隔离的逻辑层。
视图本身不能直接“构建”数据字典，但它是实现企业级通用数据维度字典最轻量、最可控、最可复用的载体。关键不在于建多少视图，而在于用视图把分散在 INFORMATION_SCHEMA、sys.columns、业务表注释、ETL元数据表里的碎片信息，按统一口径动态拼装成可查、可联、可权限隔离的逻辑层。
为什么不能直接 SELECT * FROM INFORMATION_SCHEMA.COLUMNS
因为不同数据库返回字段名不一致：COLUMN_NAME 在 MySQL 是标准字段，但在 SQL Server 中对应的是 name；Oracle 根本没有 INFORMATION_SCHEMA，得查 ALL_TAB_COLUMNS；PostgreSQL 的 data_type 值是 character varying，而 SQL Server 返回的是 varchar。硬写跨库查询会频繁报错或漏字段。
- 只依赖
INFORMATION_SCHEMA的工具，在 Oracle 或旧版 SQL Server 上基本跑不起来 - 字段注释（
COMMENT）在各库中存储位置不同：MySQL 存在COLUMN_COMMENT，SQL Server 存在sys.extended_properties，Oracle 存在ALL_COL_COMMENTS - 业务语义（如“该字段代表客户生命周期阶段”）通常不在系统表里，得从外部元数据表或配置表中 JOIN 进来
如何用视图统一拼接多源元数据
核心思路是：为每种数据库类型单独写一个底层视图，再用一个“调度视图”做 UNION ALL + 字段对齐。例如在 SQL Server 上创建 v_db_dict_sqlserver：
CREATE VIEW v_db_dict_sqlserver AS SELECT t.name AS table_name, c.name AS column_name, ty.name AS data_type, c.max_length AS length, c.precision AS numeric_precision, c.scale AS numeric_scale, c.is_nullable AS is_nullable, ISNULL(ep.value, '') AS column_comment, SCHEMA_NAME(t.schema_id) AS schema_name FROM sys.tables t JOIN sys.columns c ON t.object_id = c.object_id JOIN sys.types ty ON c.user_type_id = ty.user_type_id LEFT JOIN sys.extended_properties ep ON ep.major_id = c.object_id AND ep.minor_id = c.column_id AND ep.name = 'MS_Description'
这个视图已把物理表结构、类型、长度、注释全拉平。后续所有上层查询都基于它，不再碰原始系统表。
- 字段别名必须统一，比如一律用
table_name而非TABLE_NAME或tabname，避免下游应用大小写敏感问题 -
column_comment必须设默认值（如空字符串），否则 LEFT JOIN 后出现 NULL 会导致 BI 工具显示异常 - 不要在视图里加 WHERE 过滤（如排除系统表），那是调用方的事；视图只负责“提供全量、结构化、可解释”的原始元数据
如何让维度字典真正“通用”而非“静态快照”
真正的通用性体现在两点：能随业务表自动扩展、能按角色动态过滤。前者靠视图定义的稳定性，后者靠运行时 JOIN 权限表或上下文参数。
例如，给数据分析师只看“已上线且有业务注释”的字段，可建一个带参数的封装视图：
CREATE VIEW v_dim_dict_analyst AS SELECT d.*, b.business_desc, b.dimension_type FROM v_db_dict_sqlserver d JOIN meta_business_field b ON d.table_name = b.table_name AND d.column_name = b.column_name WHERE b.status = 'active' AND b.business_desc IS NOT NULL
- 视图不固化
WHERE条件，但可以封装常用过滤逻辑，供不同角色复用 - 如果业务字段描述存在多个来源（如 ERP 表注释 + 自研 BI 系统的标签表），用 COALESCE 拼接：
COALESCE(b1.desc, b2.tag, '未定义') - 切忌在视图里写
GETDATE()或SESSION_USER等运行时函数——多数数据库不支持在索引视图或物化视图中使用，会直接报错
容易被忽略的兼容性陷阱
视图在跨库迁移或升级时最容易暴雷的地方，不是语法，而是隐式行为差异：
- MySQL 8.0+ 默认开启
sql_mode=STRICT_TRANS_TABLES，而 SQL Server 允许 INSERT NULL 到非空字段（靠约束拦截），视图里若做了CASE WHEN计算列，两边 NULL 处理逻辑可能不一致 - Oracle 视图中对
NUMBER类型做TO_CHAR转换后，长度可能超限，导致下游报表截断；而 PostgreSQL 对numeric转字符串更宽松 - SQL Server 的视图支持
WITH SCHEMABINDING，能防止底层表结构被删改，但一旦启用，就无法修改基础表字段名——这对快速迭代的元数据管理反而是枷锁
最终交付的“通用维度字典”，往往不是一张视图，而是一组命名规范统一、职责分明的视图集合：一张负责物理结构，一张负责业务映射，一张负责权限裁剪。它们之间不嵌套过深，靠简单 JOIN 组合，才能在 Oracle、SQL Server、GBase 8a 等异构环境中真正跑得稳、查得快、改得动。
