我在MS SQL Server数据库中有一个类型为Decimal(10,6)的列.
在某些情况下，我希望该数字仅为.xx0000.
如何判断小数点后第1000位(以及之后)是否不是0？
下面是几个例子:
- 1.123456应与查询匹配
- 1.120000不应与查询匹配
- 1.000000不应与查询匹配
- 1.000001应与查询匹配
我在MS SQL Server数据库中有一个类型为Decimal(10,6)的列.
在某些情况下，我希望该数字仅为.xx0000.
如何判断小数点后第1000位(以及之后)是否不是0？
下面是几个例子:
在某些情况下，我希望该数字仅为.xx0000.
如何判断小数点后第1000位(以及之后)是否不是0？
把这个数字乘以100.那么您的查询就变成了"the number is(Not)xx.000"，意思是"该数字是(不是)整数"，或者更确切地说，是"is(Not)等于它的下限值".
WHERE (number*100) != FLOOR(number*100)
在上面的场景中，由于DECIMAL representation(我判断了MySQL，但it seems to hold for MS SQL的精度高达17位)并没有发生什么奇怪的事情:即使number达到其数据类型的存储限制，服务器也会静默地"升级"其小数存储空间，以容纳乘法的结果.所以，9999.000012乘以1,000会得到DECIMAL(14,6)值，这可以与没有损失进行比较.
在其他具有floating point个值的场景中(或者服务器没有意识到它正在处理十进制数并引入浮点数，或者您在公式中做了一个"小改动"并自己引入了这些值)，当"数字*floating point representation"恰好是is not equal到floating point representation倍于floating point representation的数字时，上述情况可能会产生误报，即(我编造了一个更大的"效果").
n = 12.6389998 // This matches...
n*100 = 1263.90000 // ...but this no longer does
如果强制转换乘法结果，则会发生不同但同样糟糕的事情，但只有在获得溢出时才会发生(因此，它似乎可以处理较小的数字，只是偶尔会中断):
WHERE CAST(number*100 AS DECIMAL(10,6)) != FLOOR(CAST(number*100 AS DECIMAL(10,6))
因此，一种更尴尬的可能性是将数字转换为字符串(据我所知，这是精确的；或者更确切地说，在数字和字符串中保持相同的近似值)，然后通过字符串操作验证它是否为LIKE '%000'.