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

Konstantin_Patrushev
Дата: 18.03.2015 14:33:26
Добрый день, коллеги)

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

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

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

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

Буду рад советам)
iscrafm
Дата: 18.03.2015 14:41:21
Konstantin_Patrushev
Добрый день, коллеги)

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

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

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

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

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

делали так. В принципе есть определенная работа в представлении данных, но много плюсов.
Konstantin_Patrushev
Дата: 18.03.2015 14:54:10
Спасибо, как раз о чем то подобном и думал)
LSV
Дата: 23.03.2015 13:42:56
В чем проблема поменять тип поля ? Геморно ? Да.

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

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

лень здесь не причем. Часто считать сантиметры значительно выгоднее, чем метры в decimal формате. Все зависит от допущений.
Konstantin_Patrushev
Дата: 23.03.2015 16:38:40
Дело в том, что далеко не всем это нужно, если менять тип поля, то придется всем.
Клиентам из РФ никому не нужно.

К тому же нужно обеспечить переход на новую версию для десятков установок ранними клиентам.
LSV
Дата: 23.03.2015 18:04:06
Konstantin_Patrushev
К тому же нужно обеспечить переход на новую версию для десятков установок ранними клиентам.
Первая пуговица застегнута неправильно -> все пуговицы застегнуты неправильно (с)

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

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

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

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

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