PostgreSQL — какой тип данных лучше использовать для валюты?

Question

[Дилик Пулатов]

В проекте точности суммы имеет значение.
Например 123456789,000456 и т.д
Хотел использовать NUMERIC но прочитал в интернет что вычисления NUMERIC значений обычно медленнее, чем целые числа. А для проекта скорость вычисления тоже важен. Остается real или double precision. Стоит ли их использовать? Или NUMERIC не так уже медленнее?

Answer 1

[Армянское Радио]

НИКОГДА. НЕ. ПИХАЙТЕ. ДЕНЬГИ. В ЧИСЛА. С. ПЛАВАЮЩЕЙ. ЗАПЯТОЙ.

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

Юзайте numeric, который был придуман именно, блин, для этой цели.

И запомните, что преждевременная оптимизация приносит зачастую больше проблем, чем пользы.

Comments

[Дилик Пулатов]

Извиняюсь, ответа я не очень понял
НИКОГДА. НЕ. ПИХАЙТЕ. ДЕНЬГИ. В ЧИСЛА. С. ПЛАВАЮЩЕЙ. ЗАПЯТОЙ
Хотите сказать лучше не использовать ни numeric ни real или double?

[Армянское Радио]

Дилик Пулатов, NUMERIC - это числа с фиксированной запятой.

[Дилик Пулатов]

Армянское Радио, а понял. спасибо. Значить будет лучше если использую вот так например NUMERIC(15,6)

[Армянское Радио]

Дилик Пулатов, если вам действительно нужны миллионные доли долларов, или что там у вас.

[Дилик Пулатов]

Армянское Радио, да такая требования)

[nApoBo3]

Дилик Пулатов, обратите внимание, что это требование распространяется не только на базу данных. В коде приложения тоже не следует для "денег" использовать типы с плавающей запятой, такие как float или double.
В разных языках программирования для этих целей используются различные типы в той или иной степени эквивалентные numeric, например decimal в java.

[Дилик Пулатов]

nApoBo3, У меня в бекенде Node js. Поэтому буду использовать библиотек bignumber.js или decimal.js

Answer 2

[Михаил]

Вообще, если говорить о деньгах, то крайне маловероятно что у вас будут доли копеек (центов и т.п.). Поэтому, можно хранить денежные суммы в виде пары "целое число" (long) + "код валюты" (целое или строка, код валюты ISO). К этой структуре, тогда, нужно иметь справочник валют, в котором будет точность валюты т.е. множитель для перевода из рублей в копейки, из долларов в центы, из евро в евроценты (1 к 100). А, например, у юаня этот множитель будет 1, так как эти денежные единицы не делятся на доли. У биткоина этот множитель будет 10^8 (сатоши).

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

Comments

[nApoBo3]

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

[Михаил]

nApoBo3, логика округления возникает только в случае деления (или умножения на нецелое число, например расчет НДС, конвертация валют и т.д.). И да, это необходимая, явная логика. Потому что деньги - это реальный объект и 1 копейка - минимальная единица. Ни в одном бухгалтерском документе не может фигурировать сумма в 0,1 или 0,01 копейку. Так что, чтобы проблемы с бухгалтерией были минимальными, логику округления тут все равно придется явно прописывать.