十进制和浮点数据类型的SQL处理

为什么会这样

weightedValue = CAST(prob*value as FLOAT(53))/CAST(totalValue as FLOAT(53))

返回完整的十进制答案，但是

weightedValue = CAST(prob*value as DECIMAL(38,14))/CAST(totalValue as DECIMAL(38,14))

返回小数点后第6位截断的十进制答案

“Prob”声明为十进制（16,14），“value”声明为十进制（17,0），“weightedValue”均为十进制值，并假设总值不超过十进制（38,14）规范

除非我遗漏了什么，否则十进制（38,14）记数法应该给出一个总数最多为38，小数精度最多为14的值。因此，我不应该在结果中遇到任何截断，不是吗

---

此外，我以前认为使用十进制（，）总是比使用浮点（）更好，因为浮点运算中隐含的不精确性以及与结果相关的不确定性——十进制（）可以用来做浮点（）可以做的任何事情，但反之亦然。我遗漏了什么？事实上，不是这样吗

问题在于SQL Server如何处理十进制除法（或乘法）

得出的精度公式如下所示：

p1 - s1 + s2 + max(6, s1 + p2 + 1)

因此，当你有一个

十进制（38,14）/DECIMAL（38,14）

时，你会得到

38-14+14+最大值（6,14+38+1）=81

因此，您的结果将是一个十进制（81,43），远远超过允许的（38,14）。因此，SQL Server会自动截断答案

有关更详细的说明，请参阅