Как создать и структурировать систему виртуальных кредитов с использованием PHP/MySQL
Каков наилучший способ структурирования системы виртуальных кредитов в PHP/MySQL?
Очевидно, мне понадобится одна таблица для каждой транзакции (дебет / кредит). Я думаю, мне понадобятся следующие столбцы в этой таблице:
TransactionID(уникальный идентификатор транзакции, начинающийся с 1 с автоинкрементом)UserID(уникальный идентификатор пользователя из основной таблицы Users)Type(заработано, куплено, потрачено и т. д.)ItemID(если потрачено на предмет)Amount(положительный или отрицательный).
ВОПРОСЫ:
1) Нужны ли другие столбцы в этой таблице?
2) Нужны ли мне какие-либо другие таблицы для этой цели?
Например, нужна ли мне еще одна таблица для отслеживания итогов каждого пользователя? Или я бы просто посчитал сумму каждого пользователя как сумму всех его транзакций?
Сначала эта кредитная система будет просто "игровыми деньгами", но я ожидаю добавить опцию "Купить кредиты" в будущем, поэтому, возможно, мне следует добавить столбец для сторонних платежных процессоров Уникальный идентификатор транзакции? Или я должен создать отдельную таблицу для купленных кредитов, а затем связать их вместе с помощью моего сценария (например, общая сумма кредитов = заработанные кредиты + купленные кредиты - потраченные кредиты)?
Помимо ответов на мои вопросы выше, я был бы признателен за любые идеи и идеи, включая ссылки на конкретные статьи о том, как это сделать, поскольку я никогда не программировал ничего подобного раньше.
Спасибо!
2 ответа
Некоторые заметки.
Я думаю, что если вы хотите построить надежную систему, которая управляет финансами, имеет смысл использовать некоторые базовые концепции из финансового мира. Я не хочу сказать, что вы должны полностью реализовать все функции учета, но многие вещи кажутся мне разумными.
Прежде всего, финансовая транзакция предполагает перемещение денег с одного счета на другой, поэтому вместо user_id Я бы использовал account_id, Каждый пользователь может иметь более 1 учетной записи, каждая учетная запись имеет тип (поиск) и валюту. Кроме того, я бы не использовал термин "пользователь" в пользу "вечеринка" (модель "партия-роль-отношение").
Во-вторых, всегда участвуют как минимум 2 стороны: деньги перемещаются с одного счета на другой. В случае покупки предмета баланс аккаунта лица уменьшается, а баланс аккаунта организации увеличивается.
Кроме того, я бы не использовал item_id, но что-то вроде event_id, Каждая транзакция связана с одним бизнес-событием. Событие - это общая родительская таблица для различных событий, которые могут произойти в вашей системе. Каждый из EventПодробная таблица будет содержать информацию, относящуюся к типу события. Например, вы можете иметь purchase_event, deposit_event, так далее.
Так как transaction таблица является предметом многих (потенциально тысяч) вставок, я не буду запрашивать ее каждый раз, когда вам понадобится баланс счета. Имеет смысл сохранить консолидированный баланс в account Таблица.
Я надеюсь, что в этом есть смысл.
Трудно что-то сказать об архитектуре базы данных, если вы не знаете, что должна делать система. Но я все еще пытаюсь.
Я не думаю, что это хорошая идея хранить столько информации в одной таблице.
Я бы сделал лучше так - transactions(id, user_id, amount, timestamp)Эта таблица содержит минимальную информацию о каждом платеже.
Все остальное хранится отдельно, например transactions_types(transaction_id, type) а также transactions_items(transaction_id, item)
О кредитах. если куплена будет та же валюта, вы просто добавляете еще один тип транзакции, а при необходимости таблицу как transactions_psid(transaction_id, psid),
Если валюта другая, все зависит от нагрузки на систему. Иметь только одну таблицу с уникальным идентификатором транзакции - это хорошо, пока не станет слишком много записей.