如何控制计算列的数据类型？

Question

使用 SQL Server 2012...

我有两列：

Price [decimal(28,12)]
OustandingShares [decimal(38,3)] -- The 38 is overkill but alas, not my call.

当我执行 ALTER TABLE 时，我得到一个作为 [decimal(38,6)] 的计算列。我需要数据类型为 [decimal(28,12)]。

ALTER TABLE [xyz].MyTable
ADD Mv AS OustandingShares * Price

如何在此计算列上有效地获得 12 位小数？我已经尝试将OutstandingShares 转换为小数点后12 位，并围绕OutstandingShares * Price 进行转换。我得到的唯一结果是 [decimal(28,12)] 处的计算域，其中有六个尾随零。

想法？

Answer 1

修复

这就是你想要的：

CONVERT(DECIMAL(28,12), (
                            CONVERT(DECIMAL(15, 3), [OustandingShares])
                          * CONVERT(DECIMAL(24, 12), [Price])
                         )
       )

用这个测试：

SELECT CONVERT(DECIMAL(28,12),
                 (CONVERT(DECIMAL(24,12), 5304.987781883689)
               * CONVERT(DECIMAL(15,3), 3510.88)));

结果：

18625175.503659806036

原因

由于 SQL Server 关于如何跨各种操作处理精度和缩放的规则，计算被截断。这些规则在 Precision, Scale, and Length 的 MSDN 页面中有详细说明。我们对这个案例感兴趣的细节是：

• 操作： e1 * e2
• 结果精度： p1 + p2 + 1
• 结果量表*： s1 + s2

这里的数据类型是：

• 十进制(28, 12)
• 十进制(38, 3)

这应该会导致：

• 精度 = (28 + 38 + 1) = 67
• 比例 = 15

但是 DECIMAL 类型的最大长度是 38。那么给出了什么？我们现在需要注意的是，“结果量表”计算附加了一个脚注，即：

* 结果精度和小数位数的绝对最大值为 38。当结果精度大于 38 时，相应的小数位数会减小，以防止结果的整数部分被截断。

所以看来，为了让 Precision 回到 38，它砍掉了 9 个小数位。

这就是我提出的修复方法有效的原因。我将“Scale”值保持不变，因为我们不想截断进入并且扩展它们没有任何作用，因为 SQL Server 将根据需要扩展 Scale。关键在于降低精度，以便不存在截断或至少最小化。

使用DECIMAL(15, 3) 和DECIMAL(24, 12) 我们应该得到：

• 精度 = (15 + 24 + 1) = 40
• 比例 = 15

40 超出了限制，因此减少 2 以降低到 38，这意味着将比例减少 2 使我们真正的“结果比例”为 13，这比我们需要的多 1，甚至会看到。

Answer 2

使用cast() 或convert()。比如：

ALTER TABLE [xyz].MyTable ADD Mv AS cast(OustandingShares * Price as decimal(12, 6)

或者你想要的任何类型。

编辑：

哦，我想我明白了。问题在于计算本身。在这种情况下，请在乘法之前进行转换，这样您就不必依赖 SQL Server 的（神秘）规则来符合十进制类型。

ALTER TABLE [xyz].MyTable
    ADD Mv AS cast(OustandingShares as decimal(28, 12) * cast(Price as decimal(28, 12))

我相信您的情况是计算结果的最大精度超过了允许的阈值，因此比例相应减小。这在page 的底部进行了解释。