Рубрики
Без рубрики

Это делает центы: выбор представления данных

Когда форматы числового представления отличаются от форматов вычислений, выбор последнего для хранения упрощает обслуживание и отладку.

Автор оригинала: Ben Lopatin.

Как вы должны хранить значение 5%? Или 10 долларов на расходы?

Эти, казалось бы, тривиальные маленькие вопросы могут вызвать боль при разработке и позволить ошибкам просочиться в программу.

Деньги

Давайте начнем с денег.

Денежные ценности представлены всевозможными способами. Один миллион долларов может быть представлен как “1 миллион долларов”, или “1 000 000 долларов США”, или “1 000 000,00 долларов США”, меньшие числа также могут быть представлены по-разному, и, как показывают эти три примера, на это влияют не только символы валюты.

Надеюсь, ваша первая мысль-сохранить номер. Хранение “$1M” может быть приемлемым, если вам нужно какое-то дополнительное кэшированное значение, но источником истины должно быть число. Это делает различные представления простыми, а также позволяет выполнять вычисления.

Но вы, вероятно, уже имели в виду числовой формат.

Это оставляет поплавки и целые числа, верно? Поплавки позволяют хранить данные после десятичной точки, а целые числа можно использовать как для целых чисел, так и для чисел с дробными значениями, заполняя сохраненную сумму, например, умножая на 100. Так какой же выбор лучше?

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

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

Для пользователей Python используйте decimal.Десятичная дробь .

Проценты

Конечно, проценты проще. 99,9% должно храниться в виде десятичной дроби(99,9) !

Не так быстро! Процент-это десятичное значение, доля от 100. Скорее всего, довольно хорошо , что если вы храните процентные значения, вы делаете какие-то вычисления с ними. В этом случае вы будете преобразовывать эти значения каждый раз, когда вы делаете этот расчет.

Вместо этого сохраните базовое значение, то есть Decimal(0.999) .

Да, вам придется преобразовать это, когда вы представляете его или сохраняете пользовательский ввод. Разница между этим преобразованием и тем, которое упомянуто в money , заключается в том, что первое преобразование целых чисел включает преобразование в неожиданный формат , в то время как ожидаемое значение процетажа в виде десятичной дроби . Таким образом, вы удаляете неожиданное преобразование из всех вычислений и добавляете понятное преобразование к пользователю и от пользователя.

Хранить в виде десятичной дроби, используя фактическое процентное значение .

Знак

Это должно быть глупо очевидно. Вы сохраняете число с любым знаком, который он имеет в вычислении. Верно?

Здесь нет правильного или неправильного ответа, скорее вам следует рассмотреть вычисления , которые вы будете выполнять с числами (если таковые имеются). Например, может быть имеет смысл хранить расход в виде отрицательного числа . Это позволит вам просто суммировать, например, значения расходов и доходов и получить результат. Конечно, вычислительно тривиально отрицать их, если они хранятся в виде положительных значений. Вопрос, опять же, в том, что ожидается? Если вы обнаружите, что часто или всегда отрицаете значение либо для вычислений, либо для представлений , возможно, имеет смысл хранить с этим знаком.

Общая нить

В каждом случае нам предлагается выбор: изменить значение для вычислений или для представления. Например, если вам нужно использовать пороговое значение в процентах , сохраняя его в виде процентного значения, 0.78 вместо 78 это означает, что меньше возможностей для путаницы и, следовательно, ошибок при обновлении вычислений. Это означает, что значение, вводимое пользователем, и значение, представленное пользователю , возможно, потребуется преобразовать. И это может быть даже больше работы. Однако риск для обслуживания и корректности кода выше.

Эмпирическое правило, которое я использую, заключается в том, насколько разумно было бы видеть это значение в базе данных, а затем выполнять с ним вычисления в SQL. Вы делите числа на какой-то произвольный коэффициент, чтобы добавить что-то разумное? Это признак того, что у вас, вероятно, есть формат представления, в котором вам нужен формат хранения.