Реализация способа хранения данных о платежах в БД и отображение баланса?

Question

[j7sx]

Добрый день. Сделал на сайте прием платежей через Bitcoinpay.

Интересует, как правильно нужно обрабатывать информацию и сколько таблиц в БД необходимо для этого.
Изначально делаю так:
1-я таблица btc_order: В ней сохраняю инфу: логин, емаил, id выставленного счета и дату.

Далее есть скрипт обработки платежей. Система отсылает на него post запрос в случае изменения статуса платежа(вышло время, оплачено и др)
Если статус платежа оплачено, то заношу данные в другую таблицу(payment_confirmed).
2-я таблица payment_confirmed: В ней храню также логин, емаил, сумму поступившего платежа и дату.

Теперь нужно отображать состояние счёта в личном кабинете пользователя. Логично, что требуется 3-я таблица с состоянием счёта в которую будут заноситься данные со второй таблицы, но как тогда быть со второй таблицей? Не удалять же ранее поступившие платежи, так как во второй таблице может храниться несколько оплат одного и того же пользователя. Разве что может заносить запись единожды, а потом просто делать UPDATE. Но хотелось бы иметь данные обо всех платежах когда либо совершенных. Может тогда в этом случае инфу о подтвержденных платежах кидать сразу в две разные таблицы. В одной будут просто все оплаты, а в другую заносить запись единожды и в ней уже делать UPDATE, если поступит еще платеж или пользователь потратит средства?

Хотелось бы узнать, как это реализовано у вас?

Answer 1

[huhrmuhr]

Ваша задача решена еще лет 20 назад в 1С
Данные, подобные вашим, хранятся вот в таких файлах DBF (аналоги таблиц в MySQL)
www.script-coding.com/v77tables.html#3.4.2.1.
Т.н. "регистр накоплений".

2 таблицы - движений и итогов

В таблице движений хранятся все изменения баланса (с плюсом и минусом).

А с помощью таблицы итогов быстро можно получить текущий баланс, даже если у вас 1 млн. клиентов и 1 млн. документов у каждого.

Если же вы предполагаете исправлять документы задним числом, то нужна еще одна таблица - для хранения последовательности. Строго говоря, это всего одна строка в таблице - а по какой момент времени лазали задним числом, это нужно чтобы инвалидировать часть записей таблицы итогов.

Система довольно надежна и даже при многократных исправлениях документов, многократных перезаписях документов, технических сбоях и т.п. - прекрасно работает.

Answer 2

[Андрей]

ну, хранить платежи и расходы в одной таблице, приход положительным числом, расход отрицательным. баланс - сумма значений

Comments

[j7sx]

Ну т.е. 3-я таблица нужна получается, в которую пользователь заносится единожды.
вот, например, запись в случае, если платёж подтвержден:
INSERT INTO payment(login, email, price, date) VALUES ('%(login)s', '%(email)s', '%(price)f', '%(date)s')

результат:
login | email | price | date

user1 | [e-mail] | 0.001 | 2016-03-10
user20 | [e-mail] | 0.1 | 2016-03-11
user1 | [e-mail] | 0.003 | 2016-03-11
..............

сюда уже не добавишь же расход и баланс, ибо придется потом скакать по всей таблице, искать пользователя, его приходы, не понятно с какого прихода потом минусовать \плюсовать. Да и в крон придется добавлять, чтоб еще даты сверял и ещё добавлять в таблицу уже обработанные даты.