SQL Server视图不能直接参数化处理多语言字典映射，但可通过统一翻译表+LEFT JOIN+CASE WHEN方式稳定承载；需避免ISNULL掩盖空值语义，推荐用内联表值函数替代动态语言切换。
SQL Server 视图能否直接处理多语言字典映射？
不能直接“自动”处理，但可以稳定承载多语言字典映射逻辑——前提是把语言标识（如 lang_code）作为显式字段纳入设计，且避免依赖 SQL Server 2005 及更早版本中不支持的 sys.dm_exec_describe_first_result_set 等动态元数据函数。
常见错误是试图用一个视图返回“当前会话语言”的列名或说明，结果发现 SELECT * FROM v_dict_zh 和 SELECT * FROM v_dict_en 无法合并成单个可参数化的视图。根本原因：SQL Server 视图不接受参数，WHERE lang = @lang 必须由上层应用或存储过程控制，不能写在视图定义里。
必须用 UNION ALL 拼接多语言字典表？
不一定。更健壮的做法是建一张统一的翻译表，再用视图按需关联：
-
dict_terms表存术语主键（如term_id、category）、业务含义（如code、value_type） -
dict_translations表存多语言内容（term_id,lang_code,display_name,description） - 视图如
v_dict_localized可 LEFT JOIN 并用CASE WHEN t.lang_code = 'zh-CN' THEN t.display_name END AS name_zh展开常用语言列 - 若需动态语言切换，应改用内联表值函数（
ITVF），例如dbo.fn_dict_for_lang(@lang)，它支持参数且可被查询优化器内联
硬拼 UNION ALL 的视图（如把 zh/en/ja 各自 SELECT 堆一起）会导致执行计划膨胀、统计信息失真，尤其当某语言缺失大量记录时，NULL 填充会干扰索引使用。
SQL Server 2005+ 中 sys.extended_properties 能否替代字典视图？
能做补充，不能替代。它适合存单语言的元数据注释（如字段说明），但有明显限制：
-
sys.extended_properties的value字段是sql_variant，实际最大长度约 7,500 字节，不适合存长描述或多语言完整文本 - 它不支持按语言维度查询：没有
lang字段，所有语言都得塞进同一个value，靠命名约定区分（如MS_Description_zh），后期维护成本高 - 无法参与
JOIN或全文检索；而自定义字典表可建全文索引、加约束、设外键，视图还能嵌套聚合 - 导出文档时，
sys.extended_properties需额外解析，而视图可直接SELECT * INTO #temp或对接 Excel 插件
为什么视图里别用 ISNULL() 包裹多语言字段？
因为会掩盖空值语义，导致业务逻辑误判。例如：
SELECT term_id, ISNULL(name_zh, name_en) AS name_display FROM v_dict_localized
表面看是“中文为空就显示英文”，但实际可能：中文字段本应存在却因同步失败为空，此时返回英文会掩盖数据质量问题。更安全的做法是暴露原始字段，让应用层决定 fallback 策略：
- 视图只提供
name_zh、name_en、name_ja等明确列 - 应用代码用
COALESCE(@lang, name_zh, name_en)控制优先级 - 或数据库层用 ITVF 返回带
is_fallback标志的结果集
视图的本质是“结构契约”，不是“业务逻辑胶水”。一旦开始在视图里揉合语言 fallback、缺省值、格式化，它就失去可测试性与复用性——这点比性能影响更值得警惕。
