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

Вот в этой теме: Правильная организация таблиц для движений денег. никто не ответил, возможно потому что вопрос напрямую не относится к 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Обижаете :)
Очень кстати подметили текущий курс. Я помню что не так давно в Беларуссии (через А намеренно, национальный колорит :)) курс был дикий. И собственно возникает очевидный вопрос, надо ли как-то девальвации в базе оформлять или это не более чем смена курса по отношению к другим валютам в определённый момент?

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

Спасибо Товарищи!

Чрезвычайно приятно и полезно для собственного обучения, общаться с такими образованными людьми :)

Товарищи, тут ещё у меня возникли вопросы.

Внесение реальных средств может быть по нескольким сценариям:
1. Авторизованный пользователь кладёт средства себе на счёт, чтобы в дальнейшем их пользовать.
2. Авторизованный пользователь оплачивает услугу на сайте используя реальные средства (не списыванимем со своего счёта)
3. Неавторизованный пользователь решает закинуть денег на сайт на определённую услугу не желая регистрироваться и в дальнейшем участвовать в судьбе внесённых средств.

Сценарии может будут и ещё, мне сейчас вот что понять. Как я начал разбираться с платёжными сервисами Я.Деньги всякие, пайпалы и т.п. В них всех создаётся запрос на оплату, т.е. формируется некий ключ транзакции и уже в случае реального проведения платежа клиентом, эта транзакция по ключу подтверждается платёжным сервисом.
Таким образом моему приложению необходимо когда клиент хочет внести денег, сперва создать уникальный ключ транзакции и в БД его сохранить. Также для последующего распределения подтверждённого платежа, мне надо в БД сохранить цель для данной транзакции (типа на счёт такого-то пользователя, от такого-то пользователя за такую-то услугу, и просто от кого-то на такой-то сервис). Как это стоит реализовывать в БД?

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


И в этой таблице соответственно userID и buyItemID - могут быть 0 и уже при подтверждении транзакции на основе payType уже или в входящие транзакции пополнения баланса пользователя (пополнение баланса), или и пополнение баланса и оплата за покупку (оплата за что-то), или просто в таблицу с внесениями денег за определённую услугу.

Застрял я что-то на этом формировании учёта движений средств.
Подскажите пожалуйста!