В каком формате чисел работать с Bitcoin в PostgreSQL?

Question

[Тарас Лабяк]

Собираюсь хранить платежы bitcoin в NUMERIC(10, 5), т.е. с точностью до 0.00001 ("битцент" ~ USD cent) максимальна сумма получается 100 000 биткоинов. Думаю это достаточно, если учесть, что минимальное начисление может быть 1% от 0.02, а минимальная сумма вывода с системы 0.01.
Только что прочитал, что операции с NUMERIC осуществляються значительно медленее чем с INTEGER (32 бита) и задумался над тем, чтобы хранит в битцентах в INTEGER. Если это в самом деле так, то я буду иметь значительний выиграш в производительности, учитывая то, что вся бизнес логика реализована в виде вюшок и процедур (функций), к примеру балас пользователя считаешься в вюшке на основе всех операций (транзакций) пользователя.
Но здесь есть и минусы, связаны с тем, что нужно конвертировать в биткоины, т.е. умножать на 100 000 и могут возникать различные ошибки (по невнемательности фронтендщика). Вообщем насколько оправдано использовать INTEGER учитывая то, что все операции осуществляются в PostgreSQL, а задача Node.js-бекенда только вызвать соответсвующую PostgreSQL-функцию.

Answer 1

[alex maslakoff]

думаю, что оправдано в integer так как не возникнет ошибки при округление. и сам js лучше будет работать с integer по той же причине.

Comments

[Тарас Лабяк]

Ошибки не будет, numeric гарантирует это. JS только для ввода/вывода в PostgreSQL, никаких критических операций с числами на нем не предполагается делать.

[alex maslakoff]

Тарас Лабяк: а где вы будете делать арифмет. операции над ними?

[Тарас Лабяк]

teke teke: говорю же - все в базе данных, кроме того, что исчисляется моментально на фронтенде

Answer 2

[Пума Тайланд]

А сколько трилионов операций в минуту вы будете делать если об этом задумались?

Comments

[Тарас Лабяк]

Вопрос сейчас так не лежит) Но в недалеком будущем станет вопрос масштабирования и производительность будет определять насколько близко это будущее)) Разрабатывается система для многократного использования в разных проектах

[Пума Тайланд]

Тарас Лабяк: я вас уверяю что проблема масштабирования и производительности у вас будет упираться далеко не в численные операции

[Тарас Лабяк]

Пума Тайланд: провел эксперемент на 32М записей - sum(integer) и sum(numeric) - 5 и 10 секунд. Это по вашему не существенно? О каких вы трильонах, если при мильонах производительость уже бросается в глаза.

[Пума Тайланд]

Тарас Лабяк: проведите эксперимент в паралель и вы будете удивлены , количество записей и количество операций вещи разные

[Тарас Лабяк]

Пума Тайланд: какую паралель? Вещий разные, количество операций = количество записей * n, в лучшем случае

Answer 3

[rPman]

Все зависит от того, где вы будете работать с базой, т.е. на каком языке и какими библиотеками будете пользоваться.
Универсальный случай - не доверяйте нецелым числам, в какой то момент вы можете получить очень неприятные округления!
Пользуйтесть целыми числами int64 (и самостоятельно делите на 10^8 при выводе и учитывайте если будете проводить умножения на такие же целочисленные значения , например при умножении на стоимость в другой валюте, которая будет храниться так же)

Если будете пользоваться php, пользуйтесь строковым представлением числа и методами BCMath - bcadd, bcdiv, bcdiv,..) таким образом даже на 32-битных системах (вам могут попасться такие виртуалки) вы не получите преобразование числа в float