视图无法实现动态币种转换——因其不支持参数、变量、函数调用、动态日期及会话上下文，且硬编码失时效、join无时间过滤易报错、精度控制不可靠；应改用内联表值函数（itvf）封装。
直接用视图封装多币种转换逻辑不可行——CREATE VIEW 不支持参数、变量、函数调用（如汇率查询）、动态日期或会话上下文，也无法执行 JOIN 到实时汇率表并做条件计算而不暴露底层结构风险。
为什么不能用视图实现动态币种转换
视图本质是保存的 SELECT 语句，它在定义时固化逻辑，每次查询都原样展开执行。而 ERP 中的币种转换必须依赖：当前汇率（通常来自 ExchangeRates 表）、生效日期范围、源/目标币种代码、以及可能的四舍五入规则。这些要素无法通过视图参数化：
-
CREATE VIEW不接受输入参数，无法传入@FromCurrency或@AsOfDate - 若硬编码汇率值（如写死
1.25），则失去时效性，且修改需ALTER VIEW，影响所有引用方 - 若
JOIN汇率表但不加时间过滤条件，可能匹配多条记录，触发“子查询返回多行”错误 - 视图无法控制精度（如强制保留两位小数），
CAST/ROUND行为在不同客户端可能因 SET 选项差异而表现不一致
推荐替代方案：内联表值函数（ITVF）
真正可复用、可参数化、性能可控的封装方式是使用内联表值函数（CREATE FUNCTION ... RETURNS TABLE）。它像带参数的视图，但支持 WHERE 条件下推、能引用其他表、可被查询优化器内联展开，无额外开销。
示例：封装基于 ExchangeRates 表的单次转换逻辑
CREATE OR ALTER FUNCTION dbo.ConvertAmount(
@Amount DECIMAL(18,4),
@FromCurrency CHAR(3),
@ToCurrency CHAR(3),
@AsOfDate DATE = NULL
)
RETURNS TABLE
AS
RETURN (
SELECT
@Amount * COALESCE(er.Rate, 1.0) AS ConvertedAmount,
er.Rate AS ExchangeRate,
er.EffectiveDate
FROM dbo.ExchangeRates er
WHERE er.FromCurrency = @FromCurrency
AND er.ToCurrency = @ToCurrency
AND er.EffectiveDate = ISNULL(@AsOfDate, (
SELECT MAX(EffectiveDate)
FROM dbo.ExchangeRates
WHERE FromCurrency = @FromCurrency
AND ToCurrency = @ToCurrency
AND EffectiveDate
- 调用时可直接嵌入查询：
SELECT o.OrderID, c.ConvertedAmount FROM Orders o CROSS APPLY dbo.ConvertAmount(o.Amount, 'USD', 'EUR', o.OrderDate) c - 函数体中不包含变量赋值或流程控制，确保是“内联”的，避免标量函数的逐行性能惩罚
-
COALESCE(er.Rate, 1.0)处理无匹配汇率的兜底，比ISNULL更符合 ANSI 标准 - 未使用
GETDATE()直接参与 JOIN 条件，而是先算出最大有效日期再关联，避免隐式转换和索引失效
如果必须用视图，只能做静态映射层
仅适用于汇率长期稳定、或仅用于报表快照场景。此时视图可作为“逻辑层”屏蔽基础表结构，但绝不承担转换计算责任：
- 把原始金额字段和币种字段一起暴露，例如
SELECT OrderID, Amount, CurrencyCode, OrderDate FROM dbo.Orders - 另建一个带有效期的汇率视图（如
v_CurrentExchangeRates），只含最新一条每对币种的记录，供下游 ETL 或 BI 工具 JOIN 使用 - 禁止在视图里写
CASE WHEN CurrencyCode = 'USD' THEN Amount * 1.25 ELSE ...—— 这类硬编码会随汇率变动频繁失效，且无法审计变更 - 若 ERP 系统本身已提供标准汇率函数（如
fn_ConvertCurrency），应优先复用其签名和行为，而非另起炉灶
真正要统一封装，核心不是“能不能用视图”，而是“谁负责获取汇率、谁决定生效时间、谁处理缺失异常”。这些决策点一旦模糊，任何语法封装都会变成技术债温床。函数可以明确边界，视图不行。
