но слишком ленив и было лень (да и кейсов не было)

в вопросах уже несколько про "почему не просто инты для денег", вот что стереотип "цент и копейка это 1/100 базовой единицы" делает

у меня был проект где надо было 0.01 центра хранить

причем баксы были

но там цена была 5 центов за 100 штук и хотелось знать цену за 1 штуку

Странно, что не 0,000001 и не биткоины 🤔

все так

в стартапчике мы пилили 5 баксов на тыщи просмотров, хранили с точностью до .8
ща в кредитах храним аналитический учет с .6

но я больше про сам забитый концепт "в валюте может быть ровно сто сабюнитов"

Это да, кстати расскажи про второй кейс

Зачем и почему

@envek дублирую вопрос сюда, ато вдруг ты не успеешь ответить, а конфу закроют: спасибо за доклад, обязательно гляну доклад про работу со времени с постгрес. В последнее время частенько возникает желание запилить вьюхи в базу, с маппингом на рельсовый объект. Есть ли у этого какие-то отрицательные стороны? реализовать вьюхи через миграции или какие-то «дефолтскоупы» ?

В Тичбейзе для этого модель просто делали, а сами вьюхи вот этим https://github.com/scenic-views/scenic делали. Но я доклад не смотрел и просто из своего опыта говорю :)

Ребят, у меня вопрос, кто-что знает по построению fingerprint кроме
https://github.com/Valve/fingerprintjs
https://github.com/Valve/fingerprintjs2

Я в итоге тоже scenic посоветовал, хоть самому пользоваться и не пришлось

Ну он работает :)
И довольно удобно

Большое спасибо всем за доклады) (тем кто на онлайн митапе)

(щя будет вайп простыней)

Я ошибся в термине, для стартапчика - да, было "храним", для кредитов корректно "ведем" - и для них я имел в виду внутреннюю точность, а не точность с точки зрения доклада Андрея, не "что и как мы персистим в базу". В базу мы эвенты суем в +- свободной форме, у нас самописный ES фреймворк :)

Аналитический и бухгалтерский учет - разные сущности. Бухгалтерский ведется в бухкниге с точностью до копейки, но если моделировать, что происходит в реальности - это "бухгалтер на калькуляторе понажимал всякое, а потом округлил в самом конце". Его не нужно вести ежедневно, но когда производятся расчеты, учитывается каждый прошедший день в отдельности. Пример - когда в день платежа рассчитывается, сколько ты должен уплатить процентов, берется ежедневный остаток и умножается на ежедневную процентную ставку (которая может меняться - например, наступил новый год, и он високосный), и это происходит *дней с предыдущего платежа* раз.

При этом даже если бухгалтерские проценты прямо сейчас тебе не нужны (ничего начислять не нужно), то для хорошего пользовательского опыта для, скажем, кредитной линии, тебе нужны актуальные аналитические проценты в разрезе дня - те-которые-бы-начислились-(отразились в бухгалтерии)-сейчас-если-ты-решил-погаситься. Можно каждый раз пытаться их считать совсем на лету по запросу, но мы их отражаем в проекциях, и у нас для этого есть выделенный эвент "ура, новый банковский день".

Если ежедневные аналитические проценты округлять каждый раз до копеечек, то накопленная ошибка образует тебе недоначисленные или переначисленные проценты и вопросы от ЦБ (в целом ЦБ допускает счетные ошибки в несколько копеек, но зачем ошибаться, если можно не ошибаться). Если пересчитывать их на диапазонах нескольких дней, как это делает реальный бухгалтер, это без выделенного тулинга становится довольно больно проверять в случае аудита. Если не округлять вообще, то опять же становится больно для аудита. Точность .6 (это 1/100000 рубля или 1/1000 копейки) была выбрана как гарантирующая отсутствие ошибки в копейку при ежедневных начислениях в пределах года, а на деле нам достаточно гарантировать отсутствие ошибки в пределах календарного месяца.

го болтать