sql-server - "Round half up"浮点值

Question

我们被困在一个(不幸的是)使用浮点数而不是十进制值的数据库中。这使得四舍五入有点困难。考虑以下示例(SQL Server T-SQL):

SELECT ROUND(6.925e0, 2)   --> returns 6.92

ROUND是否 round half up ，但由于 floating point numbers cannot accurately represent decimal numbers ，显示“错误”结果(从最终用户的角度来看)。我明白为什么会发生这种情况。

我已经想出了两种可能的解决方案(都返回一个浮点数，不幸的是，这也是一个要求):

舍入前转换为十进制数据类型:SELECT CONVERT(float, ROUND(CONVERT(decimal(29,14), 6.925e0), 2))

乘以直到第三位在小数点左侧(即准确表示)，然后进行四舍五入:SELECT ROUND(6.925e0 * 1000, -1) / 1000

我应该选择哪一个？有没有更好的解决方案？ (不幸的是，由于一些遗留应用程序访问同一个数据库，我们无法更改数据库中的字段类型。)

是否有针对此(常见？)问题的完善的最佳实践解决方案？

(显然，“四舍五入”的常用技术在这里无济于事，因为 6.925 已经四舍五入到小数点后三位——就浮点数而言这是可能的。)

Answer 1

您的第一个解决方案似乎更安全，并且在概念上似乎更适合该问题:尽快从浮点数转换为十进制数，在十进制类型中进行所有相关计算，然后在写入之前最后一分钟转换回浮点数数据库。

编辑:在检索浮点值并转换为十进制后，您可能仍需要立即进行额外的舍入(例如到小数点后 3 位，或任何适合您的应用程序的数字)，以确保最终得到十进制值实际上是有意的。 6.925e0再次转换为十进制可能(假设十进制格式具有 > 16 位精度)给出非常接近但不完全等于 6.925 的结果。 ;额外的一轮会解决这个问题。

第二种解决方案对我来说并不可靠:如果 6.925e0 的存储值怎么办？由于通常的二进制浮点问题，恰好是太小了？然后乘以 1000 ，结果可能还是在6925下摸一摸，以便舍入步骤向下舍入而不是向上舍入。如果你知道你的值总是在点后最多有 3 位数字，你可以通过在乘以 1000 后做额外的一轮来解决这个问题，比如 ROUND(ROUND(x * 1000, 0), -1) .

(免责声明:虽然我在处理其他上下文中的浮点数和小数点问题方面有很多经验，但我对 SQL 几乎一无所知。)