Целые и дробные

Добрый день, коллеги)

Уже давно делаем свой учетный софт и в силу специфики предмета учета поля в базе данных для цен всегда были целым числом.

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

Может кто встречался с подобным, как с меньшими затратами добавить поддержку дробных цен?
Важна возможность перехода с предыдущих версий.

На вскидку приходит в голову оставить в базе тип поля целое число, но добавить что то типа "коэффициент пересчета".

Буду рад советам)

Konstantin_Patrushev

Добрый день, коллеги) Уже давно делаем свой учетный софт и в силу специфики предмета учета поля в базе данных для цен всегда были целым числом. Но теперь планируем выход на зарубежный рынок и там цены могут быть дробным числом. Может кто встречался с подобным, как с меньшими затратами добавить поддержку дробных цен? Важна возможность перехода с предыдущих версий. На вскидку приходит в голову оставить в базе тип поля целое число, но добавить что то типа "коэффициент пересчета". Буду рад советам)

делали так. В принципе есть определенная работа в представлении данных, но много плюсов.

Спасибо, как раз о чем то подобном и думал)

В чем проблема поменять тип поля ? Геморно ? Да.

Но все равно же придется менять. :)
Не ленитесь.

LSV
В чем проблема поменять тип поля ? Геморно ? Да. Но все равно же придется менять. :) Не ленитесь.

лень здесь не причем. Часто считать сантиметры значительно выгоднее, чем метры в decimal формате. Все зависит от допущений.

Дело в том, что далеко не всем это нужно, если менять тип поля, то придется всем.
Клиентам из РФ никому не нужно.

К тому же нужно обеспечить переход на новую версию для десятков установок ранними клиентам.

Konstantin_Patrushev
К тому же нужно обеспечить переход на новую версию для десятков установок ранними клиентам.

Первая пуговица застегнута неправильно -> все пуговицы застегнуты неправильно (с)

А разве введение некоего коэффициента не потребует переход на новую версию ?

LSV
Konstantin_Patrushev К тому же нужно обеспечить переход на новую версию для десятков установок ранними клиентам. Первая пуговица застегнута неправильно -> все пуговицы застегнуты неправильно (с) А разве введение некоего коэффициента не потребует переход на новую версию ?

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

iscrafm
в отдельном справочнике нужно только значение множителя. Все. Никаких переделок логики, множества таблиц и т.п. не требуется.

Да неужели ! Как логика на SQL (н-р ХП или вью) узнает, что надо умножить на коэф ?
Как приложение узнает ? Как отобразит ?
Переделок не избежать. Надо смотреть по месту. Возможно это будет несложно. хз.

Хош , не хош, все равно придется много кода посмотреть/потестить, чтоб реализовать сабж.

LSV
iscrafm в отдельном справочнике нужно только значение множителя. Все. Никаких переделок логики, множества таблиц и т.п. не требуется. Да неужели ! Как логика на SQL (н-р ХП или вью) узнает, что надо умножить на коэф ?

минимум переделок, по сравнению с изменением типа данных в поле.