Всем привет. У меня стоит задача: рассчитывать баланс банковской карты.

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

Тут вопрос не во времени а в O(N). То есть чем больше транзакций тем медленее будет работать.
Быстрый вариант работает как O(1). То есть не важно сколько записей - скорость всегда одна. Это супер круто.

Один баланс это "баланс по логу транзакций" - это то что ты можешь получить если суммируешь все транзакции в таблице.

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

Если система работает верно, то оба баланса должны всегда сходиться.

С таблицой баланса всё понятно
там номер счёта и баланс юзера, собственно всё.

TABLE balance
bank_card
current_balance

А что должно быть в таблице транзакций? Какие поля?

У меня есть таблица риквестов, requests. Это по сути все риквесты на сервер. Одна транзакция это 4 запроса на самом деле:

1. первый авторизационный
2. Второй запрос на снятие или пополнение
3. Апрув
4. деклаин транзакци

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

transacctions
ID
Txn_ID
Token - токен банковской карты, он уникален и по сути это номер счёта
Amount - сколько денег надо снятьили положить
TrxType - тип транзакции это снять с банкомата, между счетами и так далее...
Status - статус трандазкции Pending, Failed, Approved


Баланс это сумма всех трназакций по конкретному счёту.
Кажись под определение така ятаблица транзакций подходит. Если это верно я задам вопрос 2

Я из вашего потока сознания ничего не понял, но вы явно ступили на длинный путь изобретения https://en.wikipedia.org/wiki/Double-entry_bookkeeping

а есть в какой-то книге по постгресу помимо статейки в вики?

Вы не заметили, что это один из основных принципов этой проклятой бухгалтерии как таковой? ;) Т.е. к постгресу не имеет никакого отношения, и вряд ли это можно найти в какой-то книге по СУБД, разве что как пример чего-то (управления транзакциями). И да, непонятно, в чём именно у Вас вопрос, IMHO.

Вопрос простой. Понятно, что если есть один сервис, который просит списать или положить бабло, то мы просто апдейтим запись. Е сли деклаин тоже апдейтим запись А если таких сервисов 4 или 5? То может быть таоке что в единицу времени ежечасно я заапрувил и снял деньги для одного сервиса(то есть сперв азабронировал денбги а потмо списал), а второй раньше забронировал и потом надо списать, то уже писывать нечего так как первый списал ранее. Конкурентое списнаие денег баланса... Что тогда делать? Это задача базы или всё же решается в коде?

Лично я бы попробовал: 1. Нормально спроектировать базу 2. Написать правильно работающие сами по себе операции 3. Использовать transaction isolation level = serializable ... 4. Profit (не надо думать о "конкурентных списаниях" и прочей низкоуровневой / не относящейся к бизнес-требованиям ерунде). "Общий" совет, конечно — но конкретных примеров Вы тоже не показали. ;)

3. Это неспортивно.

Ну так это и не спорт, а бухгалтерия (и т.д.). ;)