Товарищи, помогите пожалуйста в голове всё привести в порядок. Чё-то горожу горожу и всё чувствую что, что-то не то.
Помогите мне примером организации хранения в БД движений денег от пользователей и внутри самого приложения.

1. Пользователи могут вносить свои реальные средства с карточек в "систему". По типу платежей ВК и т.п.
2. Пользователи внутри системы могут пользовать внесённые средства.
3. Пользователи могут выводить средства из системы на свои счета (карточки, банковский счёт и т.п.)

Не могу никак соорудить схему этого всего стройную.
Как я это вижу для себя:



И вот у меня серьёзные сомнения в адекватности такой схемы. Просто всё выглядит как колосс на глиняных ногах.
Покажите пожалуйста примеры организации схемы "Внесение-вывод реальных денег, и их использование как внутриигровой валюты"

Озверин , делаю всё я и как будет лучше и правильней так и сделаю.

Кот МатроскинЕсли у Вас система совсем-совсем черная и никаких данных оттуда Вы никаким госорганам показывать не планируете - тогда да, можно решать чисто с технической точки зрения.
Ну вообще конечно надо с прицелом на легальное использование делать. Но ведь если с технической стороны учёт поступлений и выплат изначально корректным, то уже в процессе появления необходимости предоставлять какую-то определённую отчётность это можно будет сделать.
Кот Матроскин1. непонятно назначение таблицы transaction_user - это развязка многие-ко-многим между пользователями и транзакциями? Транзакция может относиться к нескольким пользователям сразу? Как-то это странно.
Нет, это значит что не за каждой транзакцией входящих средств есть зарегистрированный в системе пользователь. Может быть типа "благотворительного взноса". Когда человек не регистрируясь нажимает на кнопку пайпал к примеру и вносит определённую сумму, не регистрируясь при этом в системе.
А если в этой таблице для транзакции запись есть, то значит за ней стоит пользователь (один). Для tID можно UNIQUE указать. Я думал поле userID сделать в таблице transaction, но тогда там будет допустимо 0 в этом поле, вроде нехорошо.
Кот Матроскин2. User_money - неудачная таблица. Если хотите хранить в системе текущий баланс денег (это неоднозначное решение) - его надо хранить по счетам, а не по пользователям, иначе для пользователя, имеющего несколько счетов, будет полный бардак.
Ну вот да... Но тут вопрос в том, пользователи могут вносить ведь в разных валютах средства, и более того, даже один и тот же пользователь может внести один раз средства в рублях, второй раз в долларах. В этой таблице подразумевается хранится агрегатная информация по его приходам/выводам чтобы их не дёргать подсчётом из общей таблицы транзакций. Я тоже вроде чувствую что какая-то неразбериха грозит в случае если у каждого пользователя баланс это ещё и набор его разновалютных "счетов", но тут или вводить какие-то универсальные для всех "тугрики" в которые всё переводить, но опять же встанет вопрос с конвертацией этих "тугриков" при выводе когда курс будет другой и может случиться так, что итог конвертации для реальных счетов на которых деньги лежат будет неподходящим для системы. Вот и не знаю как это всё формализовать.

Кот Матроскин3. Что до собственно таблицы движения средств - я бы разбивал ее на 2 таблицы, master "высокоуровневая пользовательская операция" (покупка чего-то, продажа чего-то, перевод чего-то, оплата чего-то, etc.) и detail "движение денег по счетам" (то, что обычно называют проводками ). Скажем, пользовательская операция "конвертация валюты" будет порождать несколько проводок - зачисление одной валюты, списание другой валюты, комиссия, ....
поле tData, в котором Вы, похоже, хотите хранить все детали операции - тоже не лучшее решение, правильнее потратить время, продумать все детали, которые могут быть у операции, и расписать их в виде отдельных полей в master-таблице
движения. Выйдет 20 полей - значит 20, выйдет 40 - значит 40. В крайнем случае это можно оставить на второй этап и в бета-версии пожить с полем-"свалкой" - но как временным решением.Спасибо за совет. Ещё несколько раз внимательно прочитаю, осмыслю и примерю к своим идеям. А tData - да, это типа json объект туда скидывать. Ну поля добавить и из свалки сформировать, будет небольшим вопросом.
Ещё раз спасибо!