Есть параметр множитель цены, который хранится в бд и используется в проекте, вида: 5.25 т.е. 5 целых, 25 сотых Также есть модификаторы, которые увеличивают множитель цены на 10%, 50%, -40% и т.д. Для применения модификаторов их нужно постоянно делить на 100, приводя к 0.1, 0.5, -0.4. При этом, если хранить модификаторы в таком же виде 0.1, 0.5, -0.4 - их нужно будет умножать на 100 при отображении пользователю. Думаю, а не заменить ли множитель на целые числа 525, к которому просто прибавлять % модификатора: 10, 50, 40, и останется только один раз, при умножении цены на множитель цены поделить последний на 100. Возможно кто-то уже сталкивался с таким функционалом - какой вариант использовали? Какие были плюсы, минусы?
все данные лучше хранить в натуральном виде - как они есть, а вот форматировать вывод - как душе угодно. элементарно - сам через полгода посмотришь в бд и офигеешь ) че за цифры
niet, с числами не все так просто, числа - те еще мудаки. Благо, в них, в отличие от текста, данные однозначны, и не важно, в каком виде ты их хранишь, информация, которую они несут, будет той же. Гляди, когда речь идет о деньгах, а ты завел тему именно о них, то никаких дробей вообще быть не должно ни в коем случае. Потому что ошибка обработки чисел с плавающей точкой вездесуща и неистребима. Когда речь идет о деньгах, нельзя просто плюнуть и не страшно, +- что-то округлится. Деньги, или что-либо еще, чувствительное к таким вещам, принято хранить в виде наименьшей единицы измерения. Например, рубли, доллиры и прочую валюту, у которой есть копейки, храним в копейках. То есть в бд вместо 1 рубля храним 100 копеек. Вместо 1.25р храним 125 копеек. Потом при выводе надо не забывать делить на 100 и вся любовь. Да, при этом все равно есть шанс поймать ошибку округления, но она будет только в представлении для клиента. Данные сами будут в норме. Никакие проценты хранит рядом не надо. Если тебе прям нужно абстрактное хранилище дробных данных в целом виде, храни в соседней колонке 10^X, где X - это количество регистров, на которые надо запятую сместить. В случае с рублями это будет 10^2. Потом прямо тут, в селекте, вытаскиваешь произведение хранимой суммы и этого числа, получаешь готовенькое. Либо юзай вьюхи. Либо приводи руками после запроса. Вариантов масса, в общем.
Интересно, что я пока не видел ни одного двига инет-магазинов, которые бы так поступали. В том числе и Magento так не делает, хотя считается (почему-то) эталонным двигом. При этом я с тобой не спорю, просто интересный факт
хех, в нем всегда и хранил числа с плавающей запятой (с фиксированным количеством чисел после запятой) - думал он для этого и существует Всем спасибо за ответы, буду думать.
Если задача вашего движка - прочитать циферь из БД и забыть о нем, храните как хотите. Если же задача движка прочитать циферь, что-то с ним сделать, а то и обратно положить результат, то сами себе буратины, если работаете с флоатами, а не целыми числами. Децималы это очень круто, только не надо забывать, что не БД единой сервер жив.