有没有人知道为什么,使用SQLServer 2005
SELECT CONVERT(DECIMAL(30,15),146804871.212533)/CONVERT(DECIMAL (38,9),12499999.9999)
给了我11.74438969709659,
但是当我将分母上的小数位数增加到15时,我会得到一个不太准确的答案:
SELECT CONVERT(DECIMAL(30,15),146804871.212533)/CONVERT(DECIMAL (38,15),12499999.9999)
给我11.74438969
答案 0 :(得分:27)
对于乘法,我们只需将每个参数中的小数位数加在一起(使用钢笔和纸张)来计算输出dec位置。
但是师只是把你的头分开了。我现在要躺下了。
但在SQL术语中,它是exactly as expected.
--Precision = p1 - s1 + s2 + max(6, s1 + p2 + 1)
--Scale = max(6, s1 + p2 + 1)
--Scale = 15 + 38 + 1 = 54
--Precision = 30 - 15 + 9 + 54 = 72
--Max P = 38, P & S are linked, so (72,54) -> (38,20)
--So, we have 38,20 output (but we don use 20 d.p. for this sum) = 11.74438969709659
SELECT CONVERT(DECIMAL(30,15),146804871.212533)/CONVERT(DECIMAL (38,9),12499999.9999)
--Scale = 15 + 38 + 1 = 54
--Precision = 30 - 15 + 15 + 54 = 84
--Max P = 38, P & S are linked, so (84,54) -> (38,8)
--So, we have 38,8 output = 11.74438969
SELECT CONVERT(DECIMAL(30,15),146804871.212533)/CONVERT(DECIMAL (38,15),12499999.9999)
如果您将每个数字对视为
,如果也按照this rule进行,则可以进行相同的数学计算答案 1 :(得分:14)
简单地说,使用DECIMAL(25,13)并且你可以完成所有计算 - 你将获得正确的精确度:小数点前12位,后面13位小数。 规则是:p + s必须等于38,你才会安全! 为什么是这样? 因为SQL Server中的算术执行非常糟糕! 在他们修复之前,请遵循该规则。
答案 2 :(得分:10)
我注意到如果你将分频值转换成浮动,它会给你正确的答案,即:
select 49/30 (result = 1)
会变成:
select 49/cast(30 as float) (result = 1.63333333333333)
答案 3 :(得分:4)
我们对魔术过渡感到困惑,
P&P; S是相互关联的,所以:
(72,54) - > (38,29)
- 醇>
(84,54) - > (38,8)
假设(38,29)
是拼写错误且应为(38,20)
,则以下是数学:
我。 72 - 38 = 34, II。 54 - 34 = 20
我。 84 - 58 = 46, II。 54 - 46 = 8
这就是推理:
我。输出精度减去最大精度是我们要丢弃的数字。
II。那么输出比例减去我们要扔掉的东西给我们......输出比例中的剩余数字。
希望这有助于其他任何人试图理解这一点。
答案 4 :(得分:3)
转换表达式而不是参数。
select CONVERT(DECIMAL(38,36),146804871.212533 / 12499999.9999)
答案 5 :(得分:-1)
SELECT COL1 * 1.0 / COL2
这可能会有所帮助