KK
Size: a a a
2021 February 08
OD
Переслано от ORACLE DBA
Hello expert pls suggest me steps to install pgaudit on docker container
SP
Всем привет.
У меня стоит задача: рассчитывать баланс банковской карты.
Быстрый вариант рассчёта баланса: хранить текущий баланс в отдельной таблице.
Это намного быстрее, но нужно чтобы БД умела делать транзакции с условиями. Постгерс я уже прикрутил, риквесты пишутся, уря.
Тут вопрос не во времени а в O(N). То есть чем больше транзакций тем медленее будет работать.
Быстрый вариант работает как O(1). То есть не важно сколько записей - скорость всегда одна. Это супер круто.
Один баланс это "баланс по логу транзакций" - это то что ты можешь получить если суммируешь все транзакции в таблице.
И второй это "куммулятивный баланс" - это тот который ты постоянно увеличиваешь и уменьшаешь когда приходят транзакции в первую таблицу. По сути это оптимизация ради скорости. В идеальном мире хватило бы одной таблицы.
Если система работает верно, то оба баланса должны всегда сходиться.
С таблицой баланса всё понятно
там номер счёта и баланс юзера, собственно всё.
А что должно быть в таблице транзакций? Какие поля?
У меня есть таблица риквестов, requests. Это по сути все риквесты на сервер. Одна транзакция это 4 запроса на самом деле:
1. первый авторизационный
2. Второй запрос на снятие или пополнение
3. Апрув
4. деклаин транзакци
Судя по всему надо, чтобы в таблице транзакий
было поле статус транзакции, айди транзакции, та ккак в каждом запросе есть `TXn_ID`и токен банковской карты.
Ещё что-то надо может.
Баланс это сумма всех трназакций по конкретному счёту.
Кажись под определение така ятаблица транзакций подходит. Если это верно я задам вопрос 2
У меня стоит задача: рассчитывать баланс банковской карты.
Быстрый вариант рассчёта баланса: хранить текущий баланс в отдельной таблице.
Это намного быстрее, но нужно чтобы БД умела делать транзакции с условиями. Постгерс я уже прикрутил, риквесты пишутся, уря.
Тут вопрос не во времени а в 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
SI
Cмотрите. Теперь почему-то такое выходит
RL
Пишет, что нет соответствующей записи в таблице snif с id = 1.
am
Всем привет.
У меня стоит задача: рассчитывать баланс банковской карты.
Быстрый вариант рассчёта баланса: хранить текущий баланс в отдельной таблице.
Это намного быстрее, но нужно чтобы БД умела делать транзакции с условиями. Постгерс я уже прикрутил, риквесты пишутся, уря.
Тут вопрос не во времени а в O(N). То есть чем больше транзакций тем медленее будет работать.
Быстрый вариант работает как O(1). То есть не важно сколько записей - скорость всегда одна. Это супер круто.
Один баланс это "баланс по логу транзакций" - это то что ты можешь получить если суммируешь все транзакции в таблице.
И второй это "куммулятивный баланс" - это тот который ты постоянно увеличиваешь и уменьшаешь когда приходят транзакции в первую таблицу. По сути это оптимизация ради скорости. В идеальном мире хватило бы одной таблицы.
Если система работает верно, то оба баланса должны всегда сходиться.
С таблицой баланса всё понятно
там номер счёта и баланс юзера, собственно всё.
А что должно быть в таблице транзакций? Какие поля?
У меня есть таблица риквестов, requests. Это по сути все риквесты на сервер. Одна транзакция это 4 запроса на самом деле:
1. первый авторизационный
2. Второй запрос на снятие или пополнение
3. Апрув
4. деклаин транзакци
Судя по всему надо, чтобы в таблице транзакий
было поле статус транзакции, айди транзакции, та ккак в каждом запросе есть `TXn_ID`и токен банковской карты.
Ещё что-то надо может.
Баланс это сумма всех трназакций по конкретному счёту.
Кажись под определение така ятаблица транзакций подходит. Если это верно я задам вопрос 2
У меня стоит задача: рассчитывать баланс банковской карты.
Быстрый вариант рассчёта баланса: хранить текущий баланс в отдельной таблице.
Это намного быстрее, но нужно чтобы БД умела делать транзакции с условиями. Постгерс я уже прикрутил, риквесты пишутся, уря.
Тут вопрос не во времени а в 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
SP
Я из вашего потока сознания ничего не понял, но вы явно ступили на длинный путь изобретения https://en.wikipedia.org/wiki/Double-entry_bookkeeping
а есть в какой-то книге по постгресу помимо статейки в вики?
am
Второе. Вне зависимости от того, что вы там напроектировали — вам все равно понадобится таблица account с колонкой balance. Потому что если ее не будет, то из-за постгресового MVCC вам придется для корректной работы лочить всю таблицу transactions.
SP
Второе. Вне зависимости от того, что вы там напроектировали — вам все равно понадобится таблица account с колонкой balance. Потому что если ее не будет, то из-за постгресового MVCC вам придется для корректной работы лочить всю таблицу transactions.
Я кажется написал что надо 2 таблицы и та что Вы говорите там есть
SP
не надо мне третья таблица аккаунт, зачем?
am
Можете назвать ее balance. Я разрешаю.
SP
Можете назвать ее balance. Я разрешаю.
спасибо :D
SI
Roman Lukianov
Пишет, что нет соответствующей записи в таблице snif с id = 1.
ааа понятно спасибо
YS
а есть в какой-то книге по постгресу помимо статейки в вики?
Вы не заметили, что это один из основных принципов этой проклятой бухгалтерии как таковой? ;)
Т.е. к постгресу не имеет никакого отношения, и вряд ли это можно найти в какой-то книге по СУБД, разве что как пример чего-то (управления транзакциями).
И да, непонятно, в чём именно у Вас вопрос, IMHO.
Т.е. к постгресу не имеет никакого отношения, и вряд ли это можно найти в какой-то книге по СУБД, разве что как пример чего-то (управления транзакциями).
И да, непонятно, в чём именно у Вас вопрос, IMHO.
YS
Федор Гулин
Поясните плз.
Пользователи будут работать под техническими юзерами
Для схемы orx : orx_trx,
Ois : ois_trx вопрос куда сувать общие функции
Пользователи будут работать под техническими юзерами
Для схемы orx : orx_trx,
Ois : ois_trx вопрос куда сувать общие функции
Я не уверен, что понял вопрос. :(
Как вариант — в отдельную схему, куда есть доступ на выполнение функций у всех ролей, которым это нужно (ни одна из них ничем из этого не владеет, конечно).
Как вариант — в отдельную схему, куда есть доступ на выполнение функций у всех ролей, которым это нужно (ни одна из них ничем из этого не владеет, конечно).
SP
Yaroslav Schekin
Вы не заметили, что это один из основных принципов этой проклятой бухгалтерии как таковой? ;)
Т.е. к постгресу не имеет никакого отношения, и вряд ли это можно найти в какой-то книге по СУБД, разве что как пример чего-то (управления транзакциями).
И да, непонятно, в чём именно у Вас вопрос, IMHO.
Т.е. к постгресу не имеет никакого отношения, и вряд ли это можно найти в какой-то книге по СУБД, разве что как пример чего-то (управления транзакциями).
И да, непонятно, в чём именно у Вас вопрос, IMHO.
Вопрос простой.
Понятно, что если есть один сервис, который просит списать или положить бабло, то мы просто апдейтим запись. Е сли деклаин тоже апдейтим запись
А если таких сервисов 4 или 5?
То может быть таоке что в единицу времени ежечасно я заапрувил и снял деньги для одного сервиса(то есть сперв азабронировал денбги а потмо списал), а второй раньше забронировал и потом надо списать, то уже писывать нечего так как первый списал ранее.
Конкурентое списнаие денег баланса... Что тогда делать? Это задача базы или всё же решается в коде?
Понятно, что если есть один сервис, который просит списать или положить бабло, то мы просто апдейтим запись. Е сли деклаин тоже апдейтим запись
А если таких сервисов 4 или 5?
То может быть таоке что в единицу времени ежечасно я заапрувил и снял деньги для одного сервиса(то есть сперв азабронировал денбги а потмо списал), а второй раньше забронировал и потом надо списать, то уже писывать нечего так как первый списал ранее.
Конкурентое списнаие денег баланса... Что тогда делать? Это задача базы или всё же решается в коде?
am
По-моему вы хотите от нас не чтобы мы проблему решили, а чтобы мы ее сначала за вас придумали.
SP
ИК
Kirill
Всем привет! Есть сервер с PostgreSQL на котором раз в неделю выполняется бэкап pg_dumpall, который вызывается через баш скрипт в кроне. Столкнулся с проблемой, что заколнчилось место на диске и решил сжимать бэкапы через gzip backup.sql. Запустил сжатие текущего бэкапа, но случился дисконнект и операция прервалась. Подскажите как можно запустить выполнение команды, чтобы при этом можно было отключится от сервера, а команда продолжила свое выполнение?
Я посоветовал бы подключить доп диск и хранить бекапы на нем
SP
Я хочу просто узнать куда копать