2

我继承了一个使用 SQL Server 200x 的项目，其中存储在问题域中始终被视为百分比的值的列存储为其大于 1 的十进制等效值。例如，70%（0.7，字面意思）存储为70，100%存储为100等。除了需要记住 * 0.01 检索值和 * 100 持久值之前，这似乎不是问题在其本身。虽然它确实让我的头爆炸......所以我错过了它有充分的理由吗？考虑到已经编写了大量代码来处理伪百分比，是否有令人信服的理由来修复它？

在少数情况下会发生大于 100% 的情况，但我不明白为什么在这些情况下该值不会仅存储为 1.05。

编辑：头部感觉更好，并且稍微聪明一些。感谢所有的见解。

4

8 回答 8

5

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

于 2008-11-13T22:32:15.273 回答
5

实际上有四个很好的理由我能想到你可能想要存储和计算整数百分比值而不是浮点等价物：

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

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

    principle * integerPercentage / 100

    它使用所有整数算术通常比它的等效浮点更快（在浮点类型等效于 T-SQL 类型的情况下可能快得多）decimal。

于 2008-11-13T23:22:32.600 回答
4

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

例如

(0.3==3*.1)

通常是假的。

然而

abs( 0.3 - 3*.1 )

是一个很小的数字（5.55e-17）。(column-SomeValue) BETWEEN -0.0001 AND 0.0001但是必须用or做所有事情是很痛苦的ABS(column-SomeValue) < 0.0001。你宁愿column = SomeValue在你的 WHERE 子句中做。

于 2008-11-13T22:52:07.917 回答
3

浮点数容易出现舍入错误，因此在比较中可能表现得“有趣”。如果您总是想将其作为固定十进制处理，您可以选择十进制类型，例如十进制（5,2），或者执行转换并存储为您的数据库所做的 int 操作。我可能会走小数路线，即使 int 会占用更少的空间。

于 2008-11-13T22:36:46.327 回答
2

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

于 2008-11-13T22:34:17.343 回答
1

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

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

于 2008-11-13T22:54:34.667 回答
0

并且添加到数据存储问题，如果您可以使用整数算术进行任何处理，则性能比进行浮点算术时要好得多......因此将百分比存储为整数值可能允许处理逻辑整数算术

于 2008-11-13T23:05:47.467 回答
0

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

但是，如果您这样做，您应该保持一致 - 所有百分比或所有系数。

于 2008-11-13T23:06:43.380 回答