Сообщество
FAQ
Логин
Пароль
Войти при помощи
Кстати, вы можете
Общение / Веб версия / Ограничение на максимальную сумму в 21474836

Ограничение на максимальную сумму в 21474836

Александр
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
Алексей
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, это самый правильный вариант, но с этим пока проблемно, нужно обновлять железо сервера, ждём.

Альтернативный же способ несколько трудозатратен по соотношению важность/затратность.
Чтобы отвечать на сообщения - зарегистрируйтесь и войдите в личный кабинет.
© drebedengi.ru 2007 - 2017  |  Мобильная версия  |  Карта сайта  |  API интеграции  |  Обратная связь  |   English