Всем привет, вопрос насчет хранения стоимости в базе Сейчас стоимость лежит

просто в INT, соответственно все стоимости товаров целочисленные и в целом ок, так и нужно для проекта

Но вот слышал, что лучше хранить в копейках, на случай того, если цена на какой-либо из продуктов вдруг станет не целым числом

Как лучше, в копейках или просто в INT?

В базе хранить в типе number или money

А что в интах сейчас?

Да, рубли Ценник в интах стоит Сам товар цифровой и в теории копеек в цене тут не будет, поэтому хз даже как правильнее сделать, то ли оставить как есть, то ли в копейках хранить все цены, то ли вообще другой тип данных брать

Желательно мигрировать на копейки в интах

Mysql, в моей версии money и number нету

Numeric вроде имелось ввиду

Вы не сможете просто копейки записать

В принципе да, логично) Таких цен как 130р 50 коп у меня тут в принципе не предпологается конечно, но на всякий сделаю все же в копейках тогда, чтобы в будущем проблем не было)

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

Это да) А кстати если в дальнейшем будет несколько валют в проекте, то как лучше все это хранить? Делать отдельную таблицу и в ней держать цены продукта в разных валютах?

Валюта разная в пределах одногл магазина? Или просто чтобы юзер мог в своей валюте видеть?

Если он просто будет видеть в своей валюте, но будет находиться к примеру в Европе, то с оплатой могут быть траблы? И в целом для оплаты в других странах наверное уже тот же Тинькофф эквайринг не подойдет, нужно что-то вроде paypal/stripe отдельно ставить?

Платежные системы обычно принимают оплату с любой карты Visa/Mastercard, поэтому страна эмитент здесь не особо важна

Понял, тогда отлично Получается, что в таком случае нужно будет просто показать юзеру цену в его валюте? Т.е на бэке на лету по актуальному прайсу вычислить ценник и отдать на фронт?

Ну вот смотрите, на АлиЭкспресс можно увидеть цены в почти любой валюте мира, не думаю что товарищи китайцы-менеджеры сидят и постоянно вносят цену для каждой валюты для их сотни тысяч товаров Поэтому если например у бизнеса оборот весь в долларах, можно цену ставить в долларах и на лету по курсу валют на фронте конвертировать их для отображения пользователю. Но тут маленький нюанс чтобы юзер при оплате оплатил ровно такую же сумму как ему показали на странице товара, не больше и не меньше, что может случиться из за скачка курса, ошибок округления и т.д

лучше на бэке конвертировать, а еще лучше подхватывать курс и сохранять рейты с добавкой))

))

Ну бек может зафиксировать курс и фронту отдавать а фронт пусть множит и грузит девайс юзера)

Понял Да уж, с учетом того, что курс постоянно меняется, придется над этим помучаться видимо)

ну просто некоторые эквайринги за конвертацию берут денюжку, лучше это заложить в систему, чтобы не офигевать с убытков

Возьми нормальную субд

Какую?

Да именно так

Постгрес

Numeric тоже нет)

Да уже вроде как все на mysql делал, переезжать щас наверное проблематично будет

в крайнем случае всегда есть опция 🚴‍♂️ Math.round(value * 100) / 100

Это да))

https://dev.mysql.com/doc/refman/5.7/en/numeric-types.html есть такое в мускуле

У меня сейчас вообще стоит MariaDB 10.4.19 ))

decimal же есть

+

ну и юзай decimal, лучше ничего не будет