当数字大于1时，是否有充分的理由存储小于1的百分比？

Question

我继承了一个使用SQL Server 200x的项目，其中存储一个始终被视为问题域中百分比的值的列存储为大于1的十进制等值。例如， 70％（0.7，字面意思）存储为<​​em> 70 ， 100％存储为 100 等。除了需要记住检索值的* 0.01和持久值之前的* 100之外，它本身似乎不是问题。 虽然确实让我的脑袋爆炸......所以我有一个很好的理由让我失踪吗？是否有令人信服的理由来修复它，因为有相当数量的代码被编写用于伪百分比？

有少数情况会发生超过100％，但我不明白为什么这个值不会仅仅存储为1.05，例如，在这些情况下。

编辑：头部感觉更好，更聪明。感谢您的所有见解。

Answer 1

我可以想到有四个很好的理由，你可能想要存储 - 并使用整数百分比值而不是浮点数等值来计算：

1. 根据所选的数据类型，整数值可能会占用更少的空间。
2. 根据数据类型，浮点值可能会丢失精度（请记住，并非所有语言都具有与SQL Server的decimal类型等效的数据类型）。
3. 如果该值将非常频繁地输入或输出给用户，则将其保持为更加用户友好的格式可能更方便（当您计算时显示和转换时转换之间的决定...但请参阅下一点）。

4. 如果原则值也是整数，那么

   principle * integerPercentage / 100
   

   使用所有整数运算的

   通常比其浮点等价更快（在浮点类型等效于T-SQL的decimal类型的情况下，可能显着更快）。

Answer 2

如果它是一个字节字段，那么它在数据库中占用的空间比浮点数少，但除非你有数百万条记录，否则几乎看不出差异。

Answer 3

由于无法比较浮点值的相等性，因此可能已使用整数使SQL更简单。

例如

(0.3==3*.1)

通常是假的。

然而

abs( 0.3 - 3*.1 )

是一个很小的数字（5.55e-17）。但是，必须使用(column-SomeValue) BETWEEN -0.0001 AND 0.0001或ABS(column-SomeValue) < 0.0001执行所有操作，这很痛苦。您宁愿在WHERE子句中执行column = SomeValue。

Answer 4

浮点数易于出现舍入错误，因此在比较中可能会“有趣”。如果你总是想把它作为固定的十进制处理，你可以选择一个十进制类型，比如十进制（5,2），或者做转换并存储为你的数据库所做的int事物。我可能会采用小数路线，即使int会占用更少的空间。

Answer 5

一个好的猜测是因为你用整数做的任何事情（存储，计算，填充到用户的编辑等等）都比用浮点数做同样容易和高效。当你查看数据时，舍入问题就不那么明显了。

Answer 6

如果这些是最终用户可能会看到并与之交互的数字，则百分比比小数更容易理解。

这是符号辅助可以提供帮助的情况之一;在程序中，使用前缀（匈牙利语）或后缀来指定百分比值与十进制值的值是一致的。如果您可以将命名约定扩展到数据库字段本身，那就更好了。

Answer 7

为了增加数据存储问题，如果你可以对你正在进行的任何处理使用整数运算，那么性能要比进行浮点运算时好得多......因此将其存储为整数值可能允许处理整数算术的逻辑

Answer 8

如果您实际上将它们用作系数（或者期望数据库的用户在报告中执行此类操作），则存在将它们存储为系数的情况 - 特别是如果有理由进行涉及更多的计算而不是一个。

但是，如果你这样做，你应该保持一致 - 无论是所有百分比还是所有系数。