Хранение денег в БД (Postgresql)

у вс там деньга в float чтоли? тогда покури про decimal

http://www.postgresql.org/docs/8.3/static/datatype-money.html

А чем тебе numeric не угодил? Это точный тип

Почему-то мне запомнилось, что им не рекомендуется пользоваться, но не вижу ничего такого в документации.

потому что в Эфиопии и Зимбабве такая инфляция что в этот тип не вложится.

храни как беззнаковое большое целое и считай в копейках/центах. Точку добавляй уже в представлении.

а покажи ка структуру сущностей которые на этом завязаны.

цена
плавающей запятой

...

храни как беззнаковое большое целое и считай в копейках/центах. Точку добавляй уже в представлении.

какой-то мускульный подход. PG таки СУБД повёрнутая к человеку лицом и в таких костылях не нуждается. Тем более беззнаковых в PG нет

СУБД повёрнутая к человеку лицом

Через лицо sql-ем не общаются, sql-ем только чрезопу, так что не то место вы лицом назвали.

в мускуле таки есть decimal с поддержкой дробной части заданной длины

Since the output of this data type is locale-sensitive, it may not work to load money data into a database that has a different setting of lc_monetary.

а разве у постграса дампы не бинарные где пофиг на это? Я про pg_dump.

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

По умолчанию SQL, бинарный получается с опцией "--format custom". А вот у pg_restore только бинарные)

что посоветуете для хранение денежных величин?

Я думаю, ты понимаешь, что всплывшие проблемы отнюдь не от плохой реализации. Об этом плачутся уже поколения программистов, которым бухи запрещают иметь доли копейки и при этом жалуются на ошибки округления. Им нужна какая-то специальная арифметика =)

не надо бухов спрашивать, нужно хранить в базе и обрабатывать в программе с повышенной точностью (миллионные доли копеек, например), а печатать в интерфейсе и отчётах с округлением до целых копеек. Но при этом ошибки округления всё равно будут, и их надо явно оговаривать в договорах с клиентами

типа такого

«стоимость разговора округляется в большую сторону до целого числа копеек»

строчка такого вида, например, была в абонентском договоре какого-то сотового оператора

Но при этом ошибки округления всё равно будут, и их надо явно оговаривать в договорах с клиентами

Эти ошибки и будут оговорены в ТЗ: на совесть программы ляжет отслеживание этих ошибок и их автокоррекция.

Т.е. бухов не волнует, как ты там хранишь эти данные, но все отчёты «на гора» должны выдаваться без дробей и сходиться с точностью до копейки.

Гривны округляются до целых.

А разве подобное допустимо при операциях с деньгами?

у которого цена округлена почему-то вверх...

Мусье прогуливал в начальных классах арифметику? Правила округления давай вспоминай и пиши сюда.

Т.е. бухов не волнует, как ты там хранишь эти данные, но все отчёты «на гора» должны выдаваться без дробей и сходиться с точностью до копейки.

не будут они сходиться до копейки

так сходятся же :)

Наивный, видать не сдавал отчетов в ПФР. Представь - куча цифр по периодам, а потом поле ИТОГО, в котором считается сумма по периодам из _исходных_ данных, но которая естественно(так как по периодам в расчётах есть проценты) может не совпасть с суммой по периодам(п1+п2+п3). Вот и приходится кидать несколько рублей из одного периода в другой, чтобы убрать ошибки округления. Операторы связи об этом знают, вся Россия знает, но форма сделана по закону РФ, который отнюдь не математический =\

у меня поле numeric, а точность кастомно настроена как «2 знака после запятой». Может в этом дело, а может и нет...

А разве подобное допустимо при операциях с деньгами?

Ну это интернет-магазин. Так захотел заказчик, видимо ему возиться с копейками влом, а отчётность не страдает.

Или товар не возвращается на склад, т.к. изменился курс доллара и цена в гривнах уже не та..

ёпт, и эти люди еще что-то кукарекают про 1сников

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

Т.е. в итоге таблица всё-таки сходится до копейки? :)

В итоге-то сходится, но какой ценой... Бухи рыдают и стенают, домой идут уже к ночи... Самое паршивое, что фиксить это они не осиливают, и, в попытках выяснить, что кому куда по какой формуле нужно посчитать, приходится корячиться айтишникам =(

если в дампе другая точность то ничего хорошего не будет

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

не годится постгрескьюель для ынтырпрайза, академики деньги считать не умеют :)

не то что мускль

это не совсем переменные окружения, это переменные на момент когда инициализировалась БД. С lc_collate аналогичная фигня

Я честно говоря, вообще не понимаю сути проблемы. С базой никто напрямую не общается. Так зачем её вывод форматируется согласно какой-то локали? Пусть передаёт raw value которое уже db-прослойка сконвертирует во внутреннее представление программы, а отформатируется это всё перед выводом на экран пользователю.

На СУБД потому что можно переложить много функций. Любая более-менее нормальная СУБД (postgresql считаю таковой )) имеет мощный функционал для обработки множеств. Это сильно ускоряет работу ПО и позволяет скрыть от быдлокода часть бизнеслогики. Я например перекладываю на СУБД функции вычисления некоторых связанных с деньгами величин, вроде там результирующей оптовой или розничной цен. Получается очень быстро и надёжно. Если не считать проблемы с округлением :)

храните деньги в сберегательной кассе

Да я не спорю что удобно. Но просто в данном случае локаль становится источником ошибок. Вот покажите мне программиста который никогда не заливал битый дамп в базу. Или же не косячил с кодировками. А между тем эти все проблемы решаемы.

Короче, я за error-prone решения.

Вот покажите мне программиста который никогда не заливал битый дамп в базу

так не программист это должен делать, а DBAшник и отвечать за это репой. По крайней мере, везде так где дело касается денег.

Суть в том что хоть раз ошибался каждый. Так вместо того чтобы набивать шишки давайте просто сделаем так чтобы всегда всё работало вне зависимости от локали.

не надо бухов спрашивать, нужно хранить в базе и обрабатывать в программе с повышенной точностью (миллионные доли копеек, например), а печатать в интерфейсе и отчётах с округлением до целых копеек. Но при этом ошибки округления всё равно будут, и их надо явно оговаривать в договорах с клиентами

так как раз делать нельзя. Все конечные данные, т.е. которые проходят в документах и попадают в БД, хранить нужно ровно так, как говорят бухи - т.е. с точностью до копейки. Это, типа, закон - не можешь выставить счёт или что-то продать с дробными копейками (центами и т.п.).

Прорблемы с округлением возникают только в логической транзакции, например, когда нужно посчитать стоимость оказанной услуги. И только здесь можно использовать повышенную точность чтобы корректно округлить финальный результат и записать в БД. ТЗ должно оговаривать какие существуют логические транзакции и как правильно округлять в них результаты.

Если все значения хранить с повышенной точностью, то появление невязки в виде фантомных копеек неизбежно.

Все конечные данные, т.е. которые проходят в документах и попадают в БД, хранить нужно ровно

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