Лучший тип данных для хранения денежных значений в MySQL

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

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

decimal(15,2)

• 15 это точность (общая длина значения, включая десятичные разряды)
• 2 количество цифр после десятичной точки

Смотрите MySQL Числовые типы :

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

Вы можете использовать DECIMALили NUMERICоба одинаковы

Типы DECIMAL и NUMERIC хранят точные числовые значения данных. Эти типы используются, когда важно сохранить точную точность, например, с денежными данными. В MySQL NUMERIC реализован как DECIMAL, поэтому следующие замечания о DECIMAL в равной степени применимы к NUMERIC. : MySQL

т.е. DECIMAL(10,2)

Хорошо читать

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

Например, для представления значения в валюте значение 93.49должно быть сохранено как 9349при отображении значения, которое мы можем разделить на 100, и отобразить. Это займет меньше места для хранения.

Внимание: в
большинстве currency * currencyслучаев мы не выполняем умножение, в случае, если мы делаем это, то делим результат на 100 и сохраняем его, чтобы он вернулся с правильной точностью.

Это зависит от ваших потребностей.

Использование DECIMAL(10,2)обычно достаточно , но если вам нужно немного более точные значения , которые вы можете установить DECIMAL(10,4).

Если вы работаете с большими значениями, замените 10на 19.

Если ваше приложение должно обрабатывать денежные значения до триллиона, это должно работать: 13,2 Если вам нужно соблюдать GAAP (общепринятые принципы бухгалтерского учета), тогда используйте: 13,4

Обычно вы должны суммировать свои денежные значения в 13,4 до округления результата до 13,2.

На самом деле это зависит от предпочтений программиста. Я лично использую: numeric(15,4)чтобы соответствовать Общепринятым принципам бухгалтерского учета ( GAAP ) .

Попробуйте использовать

Decimal(19,4)

это обычно работает с любой другой БД

Мы используем double.

* Удушье *

Зачем?

Потому что он может представлять любое 15-значное число без каких-либо ограничений на то, где находится десятичная точка . Все за жалкие 8 байтов!

Так что это может представлять:

• 0.123456789012345
• 123456789012345.0

... и все что между

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

Один doubleполе может представлять 999,999,999,999,999s в японских йенах, 9,999,999,999,999.99s в долларах США и даже 9,999,999.99999999s в Bitcoins

Если вы попытаетесь сделать то же самое с decimal, вам нужно, decimal(30, 15)что стоит 14 байтов.

Предостережения

Конечно, использование doubleне без предостережений.

Тем не менее, это не потеря точности, как указывают некоторые. Даже если doubleсам по себе он не может быть внутренне точным для системы base 10 , мы можем сделать его точным, округлив значение, которое мы извлекаем из базы данных, до ее значащих десятичных разрядов. При необходимости это так. (Например, если он будет выведен, и требуется представление базы 10).

Предостережения: всякий раз, когда мы выполняем с ним арифметику, нам нужно нормализовать результат (округляя его до значащих десятичных разрядов) перед:

1. Выполнение сравнений на нем.
2. Запись его обратно в базу данных.

Еще один вид предостережения: в отличие от того, decimal(m, d)где база данных будет препятствовать программам вставлять число, состоящее более чем из mцифр, таких проверок не существует double. Программа может вставить введенное пользователем значение из 20 цифр, и в итоге она будет записана в виде неточной суммы.

В то время, когда этот вопрос задавали, никто не задумывался о цене биткойна. В случае BTC его, вероятно, недостаточно использовать DECIMAL(15,2). Если биткойн вырастет до 100 000 долларов или больше, нам потребуется хотя бы DECIMAL(18,9)поддержка криптовалют в наших приложениях.

DECIMAL(18,9)занимает 12 байтов пространства в MySQL ( 4 байта на 9 цифр ).

Хранение денег, BIGINTумноженное на 100 или более с целью использовать меньше места для хранения, не имеет смысла во всех «нормальных» ситуациях.

• Чтобы оставаться в соответствии с GAAP, достаточно хранить валюты в DECIMAL(13,4)
• Руководство MySQL гласит, что для хранения требуется 4 байта на 9 цифр DECIMAL.
  • https://dev.mysql.com/doc/refman/8.0/en/precision-math-decimal-characteristics.html
• DECIMAL(13,4) представляет 9 цифр + 4 цифры дроби (десятичные разряды) => 4 + 2 байта = 6 байтов
• сравните с 8 байтами, необходимыми для хранения BIGINT.

Если требуется соответствие GAAP или вам нужно 4 десятичных знака:

DECIMAL (13, 4), который поддерживает максимальное значение:

$ 999,999,999.9999

В противном случае, если достаточно 2 десятичных разряда: DECIMAL (13,2)

источник: https://rietta.com/blog/best-data-types-for-currencymoney-in/

Умножает 10000 и сохраняет как BIGINT, например, «Валюта» в Visual Basic и Office. См. Https://msdn.microsoft.com/en-us/library/office/gg264338.aspx.