Добрый день Уважаемые!

Вот в этой теме: Правильная организация таблиц для движений денег. никто не ответил, возможно потому что вопрос напрямую не относится к MySQL, потому задаю его в более подходящей ветке форума.

Итого:
Надо хранить всякие расчётно/денежные данные. Связи не так важны в данном вопросе. Важно вот что:
- Записи будут как про обычные денежные валюты, так и про различные новомодные coin'ы.

Вопросы:
1. Надо ли делать разные таблицы для coin'овых записей и обычных валют?
2. Какой имеет смысл выбрать тип столбцов для хранения сумм: Для обычных валют вроде хватит DECIMAL(15,5), а вот какой стоит выбрать для coin'ов? У них там суммы с кучами значащих цифр, есть ли какой-то достаточный вариант?

Dimitry SibiryakovИ для обычных валют и для фантиков можно использовать только целый тип, храня все суммы в
наименьшей возможной единице для данной валюты. То есть для рублей - копейки, для евро -
центы, для биткоинов - сатоши.
Дмитрий, это такое правило неписаное есть? Тут ведь в таком случае я так понимаю надо будет все входящие суммы умножать на какой-то условный 1e15 а исходящие (выводимые из БД клиенту) делить на это же число. Нет ли тут потенциального места для накопления ошибок? И в принципе на каждый чих дополнительные арифметические действия делать надо.
Cane Cat FisherТогда вам курить ПБУ 3/2006
Погляжу. Спасибо за ссылку на документ. Хотелось бы конечно чтобы вышло не для личного пользования система :)
Злой Бобресли имеете ввиду справочник валют. Нет, не справочник валют. А например список транзакций, но транзакции в разных валютах. Т.е. типа такого:


Т.е. сумма и указатель на валюту в которой эта сумма.

Спасибо всем за нет для пункта №1.

Cane Cat FisherВы действительно делаете легальный мультивалютный учет по законам РФ?
Прочитав начало документа наткнулся сразу на такие формулировки:
.....в рубли должен производиться на дату совершения операции в иностранной валюте, а также на отчетную дату.
Таблица текущих курсов валют у меня в схеме запланирована, но вместе с тем я так понимаю должно быть сохранено состояние курсов на дату совершения транзакции в валюте. И у меня тут конечно сразу возникает вопрос, а как лучше организовывать связь транзакции с курсом?
По дате? Курсы же устанавливаются на дату и в документе говорится о дате а не о моменте. Т.е. потом связывать условно по

или лучше курс хранить прямо в транзакции типа:

Cane Cat Fisher, Кот Матроскин, Dimitry Sibiryakov - Уважаемые, спасибо за полезную информацию.

Я думаю что хранить в целом не буду, потому как в любом случае для этого надо исходные данные до БД умножать на какую-то базу условную 1e15, а если потом окажется что надо было больше базу брать? Да и BIGINT - это 20 знаков, при базе в 1e15 остаётся все то 5 разрядов. Таким макаром не получится в одной таблице целочисленно хранить и какие-нибудь миллиардные беларусские рубли и койны с большим количеством знаков после запятой.
А если у DECIMAL'а надо будет больше разрядов, то увеличить их не составит труда.

Опыт "копеечных" проблем у меня уже есть, на эти грабли наступал, проблемы вылазили и я с ними в итоге справился, с тех пор отошёл от float'а на DECIMAL и при округлениях делаю всё корректно. Так что думаю что остановлюсь

Cane Cat FisherОбижаете :)
Очень кстати подметили текущий курс. Я помню что не так давно в Беларуссии (через А намеренно, национальный колорит :)) курс был дикий. И собственно возникает очевидный вопрос, надо ли как-то девальвации в базе оформлять или это не более чем смена курса по отношению к другим валютам в определённый момент?

Хотя сам понял что так и есть.