Вспомнилось, когда с блокчеином работал, там использовался gmp для больших сумм, для клиента обязательно было отображение больше 14 символов после запятой, но php во float это просто не поддерживает ))

А суммировать их без gmp сложно было. А с учетом, что хранить в базе возможно было только в decimal, так как integer не подходил - выборки по БД были не совсем быстрыми на большом объеме просто висли)))
Decimal возвращает суммы строками, в итоге строки приходилось кормить gmp для вычислений и так же в строках сохранять и работать со строками, это был Ад, так как от вычислений средствами БД пришлось отказаться))

Возможно уже что-то придумали чтобы это облегчить))

О, суммы какие были - 17,711.046433396220353322
php во float банально округляет сумму до 17711.046433396

😄

17711.046433396220353322 * 100 = 1771104.6433396 / 100 = 17711.046433396
А целостность нужна до последнего символа изначальной цены )

@LeMaX10 Привет. Проснулся и обнаружил такой прикол. В таблице где цифра меньше 1 огругляется до 0. Для импорта использую https://octobercms.com/plugin/briddle-data

Ну суммы насколько вижу норм импортируется.
А вот вес же не на 100 умножать надо...

В 1 кг же 1000 грамм

это я знаю, я и на 1000 умножал)

с суммами все ок)

Ну странно ибо те же 0,85 кг при умножении на тысячу = 850

В базе то как записано ?

я о том же) беред какой то)

Возможно просто вывод не верный ?

в базе тоже 0

хрень какая то

А тип столбца ?

При импорте лучше использовать bulk insert - тоесть не на каждую запись лепить транзакцию в базу, а собирать массив из к примеру 100 записей и импортить их одним запросом.