А
я лично в инт, умноженном на нужное колличество знаков после запятой храню
хранить можно и в decimal, а вот когда оно уже попадает в php, то надо учитывать природу float
Size: a a a
2021 February 20
VS
а в итоге, как с этим работать? в моделе есть правило, которое проверяет баланс пользователя и сумму покурки, так вот туда приходит два числа float(1715) float(1715), как оказалось второе больше чем первое
А
а в итоге, как с этим работать? в моделе есть правило, которое проверяет баланс пользователя и сумму покурки, так вот туда приходит два числа float(1715) float(1715), как оказалось второе больше чем первое
самый костыльный костыль - округлить до 9-го порядка и сравнить :)
А
а если хочется всё переделывать, то либо используй везде int, либо специальный денежный класс
Д
опыт подсказывает что лучше сразу переписать всё на bc или на инты..
Д
потом хуже будет
Д
это я прям ощутил
Д
сейчас переписал на класс, который с интом работает.
А
а если математика в БД, то вроде норм )
А
но не более, чем сложение/вычитание. Всякие умножения и деления только для статистики
DS
а в итоге, как с этим работать? в моделе есть правило, которое проверяет баланс пользователя и сумму покурки, так вот туда приходит два числа float(1715) float(1715), как оказалось второе больше чем первое
Сумму покурки?
Сайт по продаже марихуаны?😊
Сайт по продаже марихуаны?😊
Д
кто о чем ))
Д
если это сайт по продаже марихуаны, то сумму покурки, имхо, логичнее считать в косяках умноженных на цену.
Д
но тут вопрос, может ли быть, пол-косяка. и можно ли его разделить на разные счета.
А
если это сайт по продаже марихуаны, то сумму покурки, имхо, логичнее считать в косяках умноженных на цену.
так и произошло
VS
но тут вопрос, может ли быть, пол-косяка. и можно ли его разделить на разные счета.
да, у нас есть такая возможность
А
кажись цена косяка не укладывалась ровно на float и возникал небольшой float (double) косяк. При умножении цены косяка на кол-во косяков, double-косяки тоже преумножились. В сумме получился такой большой double-косяк в дроби
Д
удобны для продаванов такие double-косяки.. он вроде и есть, а вроде и нет.
А
удобны для продаванов такие double-косяки.. он вроде и есть, а вроде и нет.
не думаю. Им приходилось бы создавать разного размера оптовые партии как одну товарную единицу. Иначе суммы не сойдутся и сделка не состоится
Д
если только в программе не обнуляются эти милионные доли. а в базе сохраняются. там можно грамм-два через 1000 операций лишний вычленить