Здравствуйте!

Известно, что вещественные типы с плавающей запятой FLOAT, REAL, DOUBLE не подходят(или, можно сказать, не очень удобны) для хранения денег. Часто слышу, что деньги лучше хранить в копейках (целый тип) или в типе DECIMAL(n,2). А какой вариант лучше? В каких случаях есть преимущества(недостаток) первого варианта перед вторым? Какие условия задачи надо учитывать при выборе того или другого варианта?

Заранее благодарен
С уважением, Семен Попов

BuryCommonerПринципиальной разницы нет. С BIGINT придётся делить/умножать при операциях записи/вывода.Да, в приложении с копейками нам придется дополнительно делать обработку ввода/вывода, так же и при разных расчетах с деньгами, а это дополнительные телодвижения, операции. Но многие прогеры, особенно явисты, больше склоняются именно к копейкам. Почему так?

Mark BarinsteinИногда требуется хранить деньги с достаточно большим кол-вом знаков после запятой - для большей точности расчетов.
И тогда может сыграть большее кол-во значащих цифр у decimal (31 против 19).
В v9.5 есть ещё более удобный тип decfloat.Спасибо. Но, не представляю, как организуется логика на уровне базы для хранения дробных копеек, используя только целочисленные типы. Мне кажется, это уже усложнение. Скорее, целочисленный тип для хранения денег используется в простых задачах, где требуется хранить только деньги (реальную сумму), а не всякие там проценты, пени и т.п., которые должны иметь точность более двух знаков после запятой. Если необходимо, рассчёты этих процентов, пени и т.п. можно вынести на уровень приложения, когда это не столь часто используется. В приложении с более сложной логикой (например, в банковских приложениях) было бы логично использовать тип DECIMAL.
У меня простая задача. Хранить по людям их денежные затраты. Получать из приложения отчёт о суммарных затратах. Есть ещё НДС, но он нужен только для отчёта, поэтому эти расчёты можно вынести(?) в приложение. Хотя там тоже могу встретить проблемы с вещественными типами данных и операциями над ними.

Victor Metelitsa...
Тогда вы можете, например
1) создать таблицу (назову T) c integer_field
2) создать над этой таблицей view (назову V) с integer_field/100.00 as decimal field
3) делаете для V триггера INSTEAD OF, производящие нужные манипуляции над T
...Вот и решение. Я всё не мог додуматься, как организовать на уровне базы функционал обработки ввода/вывода копеек и различных рассчётов с ними. Спасибо.
Victor Metelitsa...
Полагаю, что само по себе суммирование для целых должно быть значительно быстрее, чем decimal (особенно в 64-хбитных системах), но доля времени на чтение с диска может оказаться настолько велика, что овчинка окажется не стоящей выделки. Поэтому для каждого конкретного случая нужно обдумывание и тестирование (конкретных данных на конкретной системе).Да, одной из причин моего перевеса в сторону целых копеек было то, что операции с целочисленными значениями выполняются быстрее. Но тут, как Вы сказали, надо учитывать и другие факторы. Будем тестировать, работать.