|
Александр
|
|
17 декабря 2010 20:45
|
|
Здравствуйте.
Натолкнулся сегодня на такое ограничение.
Моя основная валюта - белорусский рубль (на данный момент ~ 3100 BYR за 1$). Я взял кредит в 25 млн - и не смог его зафиксировать в доходах.
ps. Как программист, я прекрасно понимаю откуда такое ограничение. Просто хотел об этом сообщить.
|
|
|
|
Admin
|
|
18 декабря 2010 09:00
|
|
Здравствуйте!
Ок, спасибо, будем иметь ввиду. Как вариант пока можно несколько сумм вводить
|
|
|
|
Ilyan
|
|
18 декабря 2010 10:16
|
|
Кстати, имейте ето в виду и когда будете делать настройки количества знаков после запятой - чтобы можно было настроить не 0-1-2, но и хотя бы 3-4 знака после запятой.
|
|
|
|
Алексей
|
|
9 января 2012 13:40
|
|
За прошедший год курс белок вырос до 8450 за 1$, соответственным образом выросли и кредиты, теперь разбивать на части приходится долго и упорно.
P.S. И как программист я совсем не понимаю, с чем связана невозможность обхода такого ограничения.
|
|
|
|
Ilyan
|
|
9 января 2012 17:11
|
|
http://www.drebedengi.ru/?module=forumMessageList&topic_id=6161
|
|
|
|
Алексей
|
|
9 января 2012 17:15
|
|
Не нашёл эту тему, почитал, вижу, что вопрос актуальный и стоит на контроле. Спасибо.
|
|
|
|
Ilyan
|
|
9 января 2012 17:21
|
|
Кстати, это ограничение (как и многие другие) легко обходится в импорте.
|
|
|
|
Ilyan
|
|
9 января 2012 17:24
|
|
* Правда, введённую импортом транзакцию на миллиард нельзя будет редактировать (только удалять), но это относительно небольшая проблема.
|
|
|
|
Алексей
|
|
9 января 2012 17:29
|
|
Хотелось бы всё же иметь более интуитивный функционал, поскольку в последнее время операции происходят всё чаще и чаще..
|
|
|
|
Ilyan
|
|
9 января 2012 17:36
|
|
Неблагодарные...
Меня осенило как сделать невозможное, а они жалуются на неудобства :)))))
|
|
|
|
Алексей
|
|
9 января 2012 19:36
|
|
Меня вообще пугает, что в PHP нет поддержки безразмерных чисел с фиксированной запятой - как при этом вообще с деньгами работать!
|
|
|
|
Ivan
|
|
10 января 2012 10:37
|
|
Эм, а при чём тут пхп вообще.
Хранилище ваше поддерживать большие decimals, вся денежная арифметика у вас в хранилище (ведь в нём?). В пхп вам вернутся float, размер которого в пхп любой разрядности превышает все разумные потребности.
М?
|
|
|
|
Ivan
|
|
10 января 2012 10:44
|
|
В предвкушении что сейчас начнутся нравоучения насчёт rtfm как флоаты представляются в памяти и о невозможности представить некоторые числа с достаточной точностью заранее контр-аргументирую: в пхп не считайте ничего, доверьте это базе, она лучше с этим работает.
Если всё равно, считаете, что я ничего не понимаю - тогда жду примера, когда константный флоат (с которым, как я предложил выше, всё равно никакой арифметики не производим) с 2 знаками после запятой может криво записаться в постгрю через PDO
|
|
|
|
Алексей
|
|
10 января 2012 12:06
|
|
Простите, Ivan, вы разработчик? Если нет, не вижу причин вам это объяснять.
|
|
|
|
Ivan
|
|
10 января 2012 12:10
|
|
Алексей, я разработчик. И я же попросил привести пример, когда без арифметики в коде у вас появятся ошибки округления во флоатах на php x86.
|
|
|
|
Ivan
|
|
10 января 2012 12:14
|
|
Более того, в этом сервисе извне данные вообще приходят исключительно в виде строк. Если сервис ничего не считает в пхп (а что тут на пхп считать-то? данные пришли от клиента - положили их в постгрю), то строки отлично кладутся в decimal postgres'а
|
|
|
|
Алексей
|
|
10 января 2012 12:24
|
|
Уточню: вы разработчик Дребеденег? Тогда что же вы не реализовали этот функционал, как описываете? Касательно примера: 1234567890 - или любое другое число больше 7 значащих цифр.
|
|
|
|
Ivan
|
|
10 января 2012 12:26
|
|
Я не разработчик дребеденег. И я категорически не понимаю, почему в итоге виноватым оказался 32х-разрядный пхп.
>> Касательно примера: 1234567890 - или любое другое число больше 7 значащих цифр.
И какие проблемы при записи строки (а именно строка приходит из браузера на сервер) в decimal(42,2) postres'а вы тут видите? Я - никаких не вижу.
|
|
|
|
Алексей
|
|
10 января 2012 12:28
|
|
Ну тогда перестаньте троллить, вы точно так же не знаете, как устроена реализация, как и я.
|
|
|
|
Ivan
|
|
10 января 2012 12:32
|
|
Я не троллю, я точно так же как и вы обращаюсь к программистам ресурса - почему текущая реализация была завязана на целые в пхп. Зачем было изначально себя ограничивать.
Это же обмен опытом, от обмена опытом всем становится только лучше :-)
Объясню причину моего недоумения:
1. данные с клиентов этого ресурса и из базы приходят в строках
2. в базе используем идеологически верный decimal(p, 2)
3. во время форматирования (если оно вообще нужно в принципе) точность не теряется
4. всю арифметику производим в базе
В случае следования этим 4 очевидным тезисам никаких проблем не было бы (по крайней мере я навскидку проблемы в этом подходе обнаружить не могу, но не исключаю, что они есть).
|
|
|
|
Ilyan
|
|
10 января 2012 16:25
|
Ivan Пишет: 2. в базе используем идеологически верный decimal(p, 2) Это, кстати, не совсем верно. Например, из википедии:
Кувейтский динар — национальная валюта эмирата Кувейт, равная 1000 филсов.
|
|
|
|
Ilyan
|
|
10 января 2012 16:42
|
|
А наименьшая часть биткоина: 10 ^ (-8)
|
|
|
|
Ivan
|
|
10 января 2012 23:12
|
|
Ilyan, да какая принципиальная разница. Ну пусть это будет decimal(p, 20)
|
|
|
|
Ivan
|
|
10 января 2012 23:13
|
|
Ilyan, вон текущая реализация, судя по всему, завязана на 2 знака после запятой, и проблем снаружи с точностью не видно
|
|
|
|
Ilyan
|
|
11 января 2012 10:11
|
|
Судя по ограничению в 2^31 "копеек", существует конвертация в целое число. Поэтому я думаю, что текущая реализация в БД вообще целочисленная, где единицей является "копейка".
|
|
|
|
Ivan
|
|
11 января 2012 10:13
|
|
Ilyan, тогда при чём тут
"В БД 8-байтовые типы хорошо поддерживаются уже давно.
А вот в PHP - нет. Только на 64-бит ОС."
|
|
|
|
Ilyan
|
|
11 января 2012 11:16
|
|
Вообще-то мы ведём довольно бессмысленный спор. :)
Но мне кажется, что если бы в БД хранились не целые числа, а с плавающей точкой, не нужна была бы и конвертация в 32-битный php-integer, из-за которой и возникает проблема.
|
|
|
|
Ivan
|
|
11 января 2012 11:17
|
|
Ilyan, какие бы данные в базе не хранились - они приходят в пхп строкой. Зачем их кастовать к целому - хз вообще
|
|
|
|
Ilyan
|
|
11 января 2012 13:06
|
|
Единственная причина "кастовать к целому", которую я могу придумать - это приведение данных к формату БД. Именно поэтому я и предполагаю, что в БД суммы хранятся как 64-битные целые числа (суммы в копейках).
И да, это не оправдывает разработчиков :)
|
|
|
|
Ivan
|
|
11 января 2012 13:07
|
|
Ilyan, а есть ли смысл кастовать к "к формату в БД", если всё равно между пхп и бд у нас транспорт в виде клиентской библиотеки БД, которая принимает запросы в виде **строк** :-)
|
|
|
|
Ilyan
|
|
11 января 2012 13:26
|
|
Да, имеет. Можно сделать много проверок на валидность, не обращаясь к БД.
|
|
|
|
Ivan
|
|
11 января 2012 13:28
|
|
Ilyan, если у нас число целое, тогда проверять мы можем:
1. что у нас в строке все цифры
2. что первый знак - цифра или знак минус
3. что в строке 0 или 1 знак точки
Все эти проверки отлично делаются и на строках :-)
|
|
|
|
Ivan
|
|
11 января 2012 13:29
|
|
Но так или иначе, согласен, что мы лезем тут вообще говоря не в свои дела и занимаемся глупым процессом гадания (как минимум я, больше ни на кого не намекаю) :-)
Откланиваюсь, спасибо за дискуссию, и извините, если кого задел :-(
|
|
|
|
Ilyan
|
|
11 января 2012 13:29
|
|
Не говоря уже о том, что для реализации функциональности кнопки "=" оценивать строку все равно нужно.
|
|
|
|
Ivan
|
|
11 января 2012 13:32
|
|
Ilyan, кнопка "равно" работает на клиенте. ПХП тут снова не при чём
|
|
|
|
Glaser
|
|
21 октября 2012 12:52
|
|
Неужели за 2 года проблема еще не решилась? В Беларуси невозможно пользоваться половиной функций: бюджет, кредит, крупные покупки. 21 млн - это слишком мало. Сейчас это меньше 2500$
|
|
|
|
Admin
|
|
21 октября 2012 12:55
|
Glaser Пишет: Неужели за 2 года проблема еще не решилась? Ещё не решилась, увы.
За напоминание спасибо, приоритет этой задачи повысим.
|
|
|
|
Ilyan
|
|
21 октября 2012 18:47
|
|
Glaser, можно заносить такие транзакции через "Импорт данных" (правда, потом их нельзя будет редактировать)
|
|
|
|
Алексей
|
|
20 января 2013 20:33
|
|
Ну да, три месяца спустя повышенный приоритет виден налицо...
|
|
|
|
Admin
|
|
20 января 2013 21:20
|
|
Алексей, пока не получается эту задачу решить. Хочется решить её установкой 64 битной версии PHP, это самый правильный вариант, но с этим пока проблемно, нужно обновлять железо сервера, ждём.
Альтернативный же способ несколько трудозатратен по соотношению важность/затратность.
|
|
|
