Класс BigDecimal является стандартным способом работы с денежными единицами в Java. Однако при хранении чрезвычайно больших объемов данных (например, миллионов ~ миллиардов записей на пользователя) необходимо учитывать дополнительное место для хранения по сравнению с такими примитивами, как int: согласно этот ответит на один BigDecimal соответствует примерно 36 + Ceiling(log2(n)/8.0) байтам (не включая некоторые дескрипторы метаданных и т. д.), тогда как int чаще всего составляет 4 байт.
При хранении миллионов записей это, конечно, приведет к очень заметному увеличению не только использования памяти, но и места хранения (например, использование MongoDB с дескриптором типа или типа PostgreSQL numeric, который, кажется, соответствует по крайней мере до 8 байт, я не знаком, например, с Cassandra, поэтому я не уверен, какие последствия для хранения будут там).
Альтернативой использованию типа BigDecimal было бы сохранение целого числа центов (или любого другого наименьшего номинала, т.е. $1 == 10000 hundredths of a cent, как требуется для точности). Это не только уменьшит нагрузку на программу, но также уменьшит объем памяти, необходимый для всех, кроме самых больших значений в наборе данных (которые в любом случае будут выбросами и, вероятно, придется обрабатывать отдельно).
Это жизнеспособная альтернатива? Есть ли какие-либо подводные камни, которых следует избегать в этом случае? Соответствует ли этот подход текущим стандартам (например, внешний аудит)?
Примечание : это относится только к хранению данных, данные по-прежнему будут отображаться с надлежащим форматированием для пользователя в зависимости от различных факторов (например, языковой стандарт, например, $ 31 383,22 для США) .