Формат денег

[Burzum]

Всех приветсвую.
Подскажите, плз, какой формат лучше всего использовать для хранения денег Float, Numeric, Decimal или Integer (делить на 100)? В каком формате не возникнет проблем с округлением?
Заранее спасибо.

[kdv]

ну уж явно не float. и почитал бы ты документацию, по типам данных (DataDef.pdf). а то как то double precision совсем не упомянул

[Vemer]

Сам храню и другим всегда советую хранить в виде Integer в копейках, а вид менять на клиенте (onGetText для Delphi например). Если нужна большая точность - можно увеличить, размера Int хватит.

[Burzum]

2 Vemer: Спасибо большое за подсказку.

2 kdv: в документации, FAQ, статейках и т.п. читал совершенно разные мнения, потому решил спросить совета у народа. Но все равно спасибо за наводку.

[kdv]

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

в документации, буде она английская, написано что вещественные числа предназначены только для хранения "научных" чисел, коими "деньги" не являются. В третьем диалекте и спрашивать нечего - объявляешь numeric(15,2), например, и все.

Про float никогда не слышал что его "желательно" использовать, ибо в нем точность всего 7 знаков. Также не слышал и "совершенно разных мнений".
Ибо, integer хватает не всем. в диалекте 1 приходилось использовать double precision "мучаясь" с округлением (udf). В диалекте 3 думать не надо, numeric(15,2) сам будет хранить данные в int64. но там есть другие проблемы (если ты читал migration.htm).

[fwp]

Ибо, integer хватает не всем. в диалекте 1 приходилось использовать double precision "мучаясь" с округлением (udf). В диалекте 3 думать не надо, numeric(15,2) сам будет хранить данные в int64. но там есть другие проблемы (если ты читал migration.htm).

Иногда возможно потребуется Numeric(18,4)

[kdv]

ну вот. читайте тогда документацию, чтобы понять, чем отличается numeric(15, 2) от numeric(18,4).

[Vemer]

Numeric это конечно замечательно, но проблема в том, что например Delphi не умеет складывать дроби нормально. А с Integer таких проблем не возникает. Ведь часть расчетов всяко на клиенте удобнее делать. И насколько я знаю, многие банковские системы хранят в целом виде (4 знака), тоже наверно не просто так.

[Гость]

Сам храню и другим всегда советую хранить в виде Integer в копейках, а вид менять на клиенте (onGetText для Delphi например). Если нужна большая точность - можно увеличить, размера Int хватит.

Единственная засада - это когда по полю cena integer делаешь sum.
Sum получается тоже integer а при сложении можно и вылезти за integer. Решениемв данном случае является приведение типа результата к BIGINT например, или Decimal.

[Vemer]

To Гость.
В принципе верно, но с моими задачами Int справляеться пока.

[Deem]

numeric (15,2). А VCL таки дурной. Свои фукции пришлось сделать

[DSKalugin]

Я тоже интересовался этим вопросом
и получил 40 ответов
http://www.delphimaster.ru/cgi-bin/foru ... 822358&n=1
[quote=Я]
Объясняю популярно почему нежелательно использовать NUMERIC(х,2)
Дана цена 100евро
попустим ее надо умножить на дробь 1/1.2 в каких-то целях
1/1.2=0.81300813008130081300813008130081~ в периоде общем
но поскольку точность 2 знака после запятой фактическое умножение будет на 0,81
отсюда и погрешность 2,33 евро на сотню. Т.е. 2,33%
В магазине оборот десятки тысяч. Вот и прикиньте к чему приведет такая точность[/quote]
в итоге плюнул на этот базар и выбрал double precision
Правильно?

[kdv]

чушь. наоборот, вещественные числа теряют точность. и любые бухгалтерские вычисления обязательно считаются только до определенного знака. К тому же, любой числовой тип может хранить только определенное число ЗНАКОВ, независимо от положения запятой (отделяющей дробь от целого числа). В общем, читал бы ты лучше www.ibase.ru/ibfaq.htm#float. Там есть ссылка на шикарную большую статью про это.