Как хранить и работать с деньгами в коде и базе данных?

Question

[arturich]

Вопрос решен. Использовать int предпочтительнее и по скорости и по размеру данных, которые могу в нем храниться. Ниже подробности.


Давайте попробуем раз и навсегда обсудить и понять как хранить и работать с денежными суммами.


Я изучил вопрос и понял, что люди разделились на два лагеря:


1) Хранение в int

2) Хранение в decimal


Допустим, что мне достаточно вести биллинг в рублях с точности до копеек.

Хранение в bigint

Плюсы:

• Нет плавающей точки — меньше неточностей
  
• Можно производить стандартные мат. операции и не бояться, что потеряешь где-то копейки
  
• mithraen: Мат. операции идут быстрее (От автора вопроса — я проверил. Расчеты ниже)
  
• gleb_kudr: Вот международный стандарт по денежным единицам en.wikipedia.org/wiki/ISO_4217
  
  Там видно, что число знаков после запятой у них может быть разное. А значит для простоты разработки, все стоит хранить в минимальной дробной денежной единице валюты, осущеставляя конвертацию при выводе (т.е. в int)
  

Минусы:

• Надо помнить о постоянном умножении/делении на 100
  

Хранение в Deciamal/Numeric

Плюсы:

• Храниться в естественном виде
  
• Не надо дополнительно париться при выводе
  

Минусы:

• При неаккуратной работе (не через bcmath) можно ошибиться при умножении или делении
  
• Работа через bcmath медленее
  
• У разной валюты разное кол-во знаков поле запятой — если у вас мультивалютная система, будет избыточность данных. Придется делать более 2 знаков после запятой, но они будут нужны не всем
  
• Роберт Мартин: «Использовать числа с плавающей точкой для представления денежных сумм — почти преступление»
  

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

Замеры скорости

Примеры приведу на языке php.

Работа с плавающей точкой

<?php
$a = 1.2;
$b = 3.4;

for ($i=0;$i<1000000;$i++) {
    $c = bcdiv($a,$b,2);
}

Запускаем:

arturgspb@debian:/home$ time php 1.php

real    0m3.490s
user    0m3.468s
sys     0m0.020s

Работа с Int

<?php
$a = 11.2;
$b = 3.4;

$a *= 100;
$b *= 100;

for ($i=0;$i<1000000;$i++) {
    $c = $a/$b;

    // Избавляемся от лишних чисел
    $c *= 100;
    $c = (int)$c;
    $c /= 100;
}

Запускаем:

arturgspb@debian:/home$ time php 2.php

real    0m0.562s
user    0m0.540s
sys     0m0.020s

Разница скорости в 6 раз очевидна.

Answer 1

[gleb_kudr]

Вот международный стандарт по денежным единицам en.wikipedia.org/wiki/ISO_4217
Там видно, что число знаков после запятой у них может быть разное. А значит для простоты разработки, все стоит хранить в минимальной дробной денежной единице валюты, осущеставляя конвертацию при выводе (т.е. в int)

Answer 2

[m08pvv]

Есть хорошее обсуждение на stackowerflow

Comments

[arturich]

Я так понимаю decimal?

[m08pvv]

Если база данных, например, MS SQL, то можно тип MONEY

[arturich]

Я использую postgresql. Проверил там — получилось, что число «999999999999999999» (это в копейках) вставилось только в int8 и money. В numeric банально не хватило места, хотя я убрал две девятки.

Money мне учтиво ставит знак доллара. Локаль, понятно. Но что если у меня много валют (я просто не в курсе как это организуется тогда)?

test=# select * from "money";
        int         |      numeric      |           money
--------------------+-------------------+---------------------------
  12345678901234599 |   123456789012345 |   $123,456,789,012,345.00
 999999999999999999 | 10000000000000000 | $9,999,999,999,999,999.99
(2 rows)

Answer 3

[mithraen]

int удобнее.

Мы просто считаем что все суммы у нас указаны в копейках. И все математические операции выполняются крайне быстро. А понятие «рубли/копейки» имеют смысл только при вводе/выводе.
Там и конвертировать.

Answer 4

[AR1ES]

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

Comments

[arturich]

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

Answer 5

[Melkij]

> Если пишите что-то вроде «деньги нельзя хранить в float» — пишите почему именно.
Как почему? Потеря точности и постоянные округления, конечно. И весьма забавные вычисления около нуля.
Но при чём тут float, когда рассматриваете int и decimal?

Ещё одно «за» int — тупое целочисленное действие. В отличии от decimal, не являющегося простым типом данных.

Comments

[arturich]

> Потеря точности и постоянные округления, конечно.
Про какие, например, округления вы говорите? bcmath точно считает

> И весьма забавные вычисления около нуля.
Поясните, пожалуйста.

> Но при чём тут float, когда рассматриваете int и decimal?
Это я на всякий случай написал, от крикунов, которые вообще ничего не смыслят. Вы можете не обращать внимания.

[Melkij]

> Про какие, например, округления вы говорите?
Postgres, тип поля float:

update floattest set val=0.05;
update floattest set val=val+10000;
update floattest set val=val-10000;
-- всё штатные транзакции не так ли?
select val from floattest ;
=>  0.0499999999992724

А хде мои 50 копеек? Вот тут и придётся округлять.

> Поясните, пожалуйста.
См. пример выше. Просто встречается значительно чаще, что баланс на ровном месте гуляет вокруг нуля, внезапно отрицателен, но очень редко, когда действительно равен 0.

[arturich]

> Postgres, тип поля float:
Я про float и не говорю. Он вообще нигде точный не будет так как стандарт этого не предполагает. А с numeric в posgtres все в порядке и очень точно.

Answer 6

[Edro]

используем oracle+number
ни каких проблем не испытываем

Comments

[arturich]

Мы пока на postgres тоже не испытываем. А какой язык программирования вы используете?

[Edro]

pl\sql

[arturich]

Вы только в БД эти данные обрабатываете?

[Edro]

да

Answer 7

[Кирилл]

А у меня вопрос про суммы списания. Как хранить отрицательные суммы в базе? Со знаком минус или добавить тип записи debit & credit ? Но как тогда быстро одним запросом посчитать сумму всех записей?

Comments

[Roman]

мы хранили со знаком минус, при суммирование не было проблем

Answer 8

[ryabininea]

Данный вопрос до сих пор терзает нас! )

Смотрите, когда два знака после запятой, все норм, все понятно. А как же быть, допустим, если мне необходимо хранить по 7 знаков до, и 7 знаков после. Будет ли bigInt лучше numeric (decimal)

Буду благодарен, если кто-либо даст ответ с учетом особенностей базы данных PostgreSQL.

Comments

[arturich]

Вот выше уже отвечал человеку Как хранить и работать с деньгами в коде и базе данных?

[ryabininea]

arturgspb: Простите, просто неявно, что имеется ввиду bigInt. Может там число {1},{7}, а не {9},{9}

[arturich]

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

[ryabininea]

arturgspb: Спасибо за помощь

Answer 9

[Sergey Belov]

Если соберетесь хранить деньги и делать обмен валют - рекомендую презентацию 2013.zeronights.ru/includes/docs/Adrian_Furtuna_-_...

Answer 10

[abratko]

Здесь https://www.postgresql.org/docs/9.5/static/datatyp... (раздел 8.1.2)
рекомендуют NUMERIC

Comments

[arturich]

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

[abratko]

А какая у вас точность и масштаб, если не секрет?

[arturich]

abratko: Где как, для тех, валют, с которыми работает обычно двух знаков хватает. Супер биллингов нет, потому не сказать, что сильно тратим время на такие запары, как правило все сводится просто к храниению, выводу и правки через UI и иногда умножением на 1млн. чтоб куда-нить в api заслать

Answer 11

[yoda_code]

Там видно, что число знаков после запятой у них может быть разное. А значит для простоты разработки, все стоит хранить в минимальной дробной денежной единице валюты, осущеставляя конвертацию при выводе (т.е. в int)

Согласен с полезностью хранения в int. Однако, стоит помнить и о дополнительной точности, а не только о минимальной дробной единице самой валюты. Пример, клиент вносит сумму 0,02 или 2 цента. В базу вы пишете в центах, 0,02×100=2, у вас пойдет 2. Но, что если нужно списать комиссию в 10%? 2×10%=0,2. Понадобится дополнительная точность, т.е. введение дополнительного нуля, делить\умножать на 1000, а не на 100. Или решение этого вопроса другим способом.