Есть ли веская причина хранить проценты, которые меньше 1, как числа больше 1?

Question

Я унаследовал проект, использующий SQL Server 200x, в котором столбец, в котором хранится значение, которое всегда рассматривается как процент в проблемной области, хранится как его десятичный эквивалент, превышающий 1. Например, 70% (буквально 0,7) сохраняется как 70 , 100% как 100 и т. Д. Помимо необходимости помнить * 0,01 для извлеченных значений и * 100 перед сохранением значений, само по себе это не является проблемой. Это заставляет мою голову взорваться, хотя ... так есть ли веская причина для этого, что я скучаю? Есть ли веские причины, чтобы исправить это, учитывая, что написано достаточно кода для работы с псевдопроцентами?

Есть несколько случаев, когда происходит более 100%, но я не понимаю, почему значение не будет просто сохранено, например, как 1,05.

РЕДАКТИРОВАТЬ: Голова чувствует себя лучше, и немного умнее. Спасибо за все идеи.

Answer 1

На самом деле есть четыре веские причины, по которым я могу подумать, что вы, возможно, захотите хранить - и рассчитывать - процентные значения целых чисел, а не эквиваленты с плавающей точкой:

1. В зависимости от выбранных типов данных целочисленное значение может занимать меньше места.
2. В зависимости от типа данных значение с плавающей запятой может потерять точность (помните, что не все языки имеют тип данных, эквивалентный типу decimal SQL Server).
3. Если значение будет вводиться или выводиться пользователю очень часто, может быть удобнее сохранить его в более удобном для пользователя формате (решение между преобразованием при отображении и преобразованием при вычислении ... но посмотрите следующий пункт).

4. Если значения принципа также являются целыми числами, то

   principle * integerPercentage / 100
   

   , который использует всю целочисленную арифметику, обычно быстрее, чем ее эквивалент с плавающей точкой (вероятно, значительно быстрее в случае типа с плавающей точкой, эквивалентного типу decimal в T-SQL).

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. Вы бы предпочли column = SomeValue в предложении WHERE.

Answer 4

Числа с плавающей запятой склонны к ошибкам округления и, следовательно, могут быть «забавными» в сравнениях. Если вы всегда хотите иметь дело с ним как с фиксированным десятичным числом, вы можете выбрать десятичный тип, скажем, десятичный (5,2), или выполнить преобразование и сохранить как int, что делает ваша база данных. Вероятно, я бы пошел по десятичному маршруту, хотя int будет занимать меньше места.

Answer 5

Хорошая догадка состоит в том, что все, что вы делаете с целыми числами (сохранение, вычисление, вставка в редактирование для пользователя и т. Д.), Немного проще и эффективнее, чем то же самое с числами с плавающей запятой. И вопросы округления не так очевидны, когда вы смотрите на данные.

Answer 6

Если это числа, которые конечные пользователи могут видеть и взаимодействовать с ними, проценты легче понять, чем десятичные дроби.

Это одна из тех ситуаций, в которой может помочь вспомогательное средство записи; в программе будьте последовательны в использовании префикса (венгерского) или постфикса для указания значений в процентах по сравнению с десятичными. Если вы можете распространить соглашение об именах на сами поля базы данных, тем лучше.

Answer 7

Если вы на самом деле используете их в качестве коэффициента (или ожидаете, что пользователи базы данных будут делать подобные вещи в отчетах), есть смысл сохранить их в качестве коэффициента - особенно если есть причина для выполнения расчетов, включающих больше чем один.

Однако, если вы сделаете это, вы должны быть последовательны - либо все проценты, либо все коэффициенты.

Answer 8

И чтобы добавить к проблеме хранения данных, если вы можете использовать целочисленную арифметику для любой обработки, которую вы делаете, производительность намного выше, чем при выполнении арифметики с плавающей запятой ... Поэтому сохранение значений в виде целочисленных значений может позволить обработку логика для выделения целочисленной арифметики