Логика и структура БД для работы с балансом и транзакциями

Question

[Виктор Сафронов]

У меня планируется приложение, в котором у пользователей будет понятие баланса. Также будут транзакции, которые этот баланс изменяют в одну или другую сторону — зачисления и списания. Некоторые списания будут реализованы по схеме, когда пользователь запрашивает его, а некий модератор спустя время подтверждает. Или не подтверждает :)
Вопроса, собственно, два. Нужно ли хранить входящий/исходящий баланс в истории транзакций? Это очень пригодится для построения отчётов, чтобы можно было в случае чего найти нестыковки.
С другой стороны, как быть с неподтверждёнными транзакциями. Либо не считать их таковыми до подтверждения вообще и хранить в отдельной таблице запросов (но, блин, зачем плодить разные таблицы, если это можно хранить в одной?). Получается, что пока списание не подтверждено, входящий и исходящий баланс одинаковы. И потом после подтверждения нужно пробегать по всем последующим (если таковые успели появиться) и обновлять у них соответствующие поля, что выглядит мне противоречащим здравому смыслу.
В общем, буду рад идеям :)

Answer 1

[1x1]

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

Т.е. сначала просто блокировка средств на счету. Добавьте это поле и всё будет просто.

Нужно ли хранить входящий/исходящий баланс в истории транзакций?

Это удобно, но и без них многие работают.

С другой стороны, как быть с неподтверждёнными транзакциями.

Если вы позволяете использовать средства до подтверждения, то зачислять как обычно, а в случае неподтверждения добавлять отменяющую транзакцию. Если нет — транзакция происходит только в момент подтверждения платежа; платеж и транзакция по изменению баланса — разные сущности.

Comments

[Виктор Сафронов]

Да, о блокировке я не подумал, а надо бы. Потому что при запросе на списание сейчас проверяются только условие $amount < $balance, а нужно учитывать и «висящие» деньги. В принципе, имея это поле, можно решить все остальные проблемы.

Answer 2

[sonic]

Баланс храни в отдельной таблице.

Comments

[Виктор Сафронов]

Прошу прощения, как и зачем?

Answer 3

[sonic]

Вид документа потвержденный непотвержденный. Дата время изменения.

Comments

[Виктор Сафронов]

Огурец ножницы дрель. Чайная ложка беспокойствие.

Примерно такими я вижу ваши ответы. Если вы поняли мои вопросы и проблемы, и знаете как их решить, то предложите, пожалуйста, свой вариант. Но зачем писать урывками непонятные вещи?

Answer 4

[Андрей Смирнов]

Недавно делал похожую систему.
Баланс пользователя хранится отдельно, там фиксируется актуальное «реальное» число условных единиц.
Есть таблица транзакций, с описанием, датой, суммой, направлением списания (на баланс или с баланса), поле «заморозка» и поле «статус».

Соответственно, на клиенте показывается реальное число, показывается, исходя из списка транзакций, сколько денег на счету заморожено (такие транзакции, как правило, лежат с состоянием «на проверке» и галочкой в поле «заморозка» до тех пор, пока их не подтвердят, тогда галочка снимается, и замороженная снимается со счета).

В принципе, вполне хватает для всех нужд. Как только транзакция проводится, ее статус меняется на «исполнена», и деньги вычитаются уже из таблички пользователей.

Comments

[Виктор Сафронов]

промазал habrahabr.ru/qa/47148/#answer_176268

Answer 5

[Виктор Сафронов]

Баланс отдельно — имеется в виду отдельное поле в таблице с пользователями?

Для отображения на клиенте всякий раз строится сумма по транзакциям и в этот момент актуализируется то отдельное число? Я, кажется, не всё понял :)

Answer 6

[Illivion]

Я считаю (и делаю :) ), что непотвержденные транзакции суть есть совсем не транзакции, а сущности запросов. Таким образом имеем 2 таблицы. Одну с запросами, где держим данные типа «кто, сколько, когда создал, когда отменил или подтвердил», а вторую уже с записями — фактическими движениями средств. Если заявка подтверждается модератором — создается запись в транзакциях.

Хранить входящий и исходящий балансы правильно в том случае, если вам потребуются отчеты, где будет выборка по периодам дат, и где нужно будет показать «входящий остаток» на начало этого периода. Вот тут-то оно очень сильно пригодится. Ибо считать его по транзакциям больно накладно получается (особенно, если их много очень)

Comments

[Виктор Сафронов]

А в чём смысл отдельной таблицы, в которой будут практически все те же поля?
Я склоняюсь в сторону одной таблицы, чтобы на странице «История» одним селектом отображать всю активность по счёту, включая неподтверждённые ещё запросы.