Костыль на костыле: как я больше двадцати лет лечил остатки вместо того, чтобы найти причину

[atues]

Ох, как же это знакомо :) Я начинал программистом в банках, как и автор. Только чуточку раньше - в 1993 году. И вопрос об остатках был в числе первых: единая таблица остатков (быстро, но чревато) или только таблица транзакций (медленно, но надежно). Остановились, как и автор, на таблице остатков (кажется, в те годы практически все так и делали: железо было слабеньким, SQL знали немногие, зато всяких DBF-систем было завались сколько). Со временем стало понятно, что рано или поздно это решение так себе. Когда транзакций 500-1000-2000 в день, то корректировка остатков худо бедно, но была оправданной. Но все, что выше - уже чревато: сутками искать где и что перекосило удовольствие так себе. Да, писали утилиты по типу той, что говорил автор. Но, по большому счету, это путь тупиковый. И перешли на транзакции, благо железо стало сильно получше, да и SQL перестал быть экзотикой )

[Timur555]

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

[Gromilo]

А нельзя было использовать не один остаток, а остатки по дням? или часам?

И считать как остаток на начала дня + все транзакции?

[Timur555]

именно так и работало:
- остаток на утро берем готовый из таблицы
- все операции с начала дня считаем с учетом знака
- получаем текущий остаток в моменте

Остатки по часам - это было бы десятикратное усложнение там, где оно не особо то и нужно

[Gromilo]

Понял, просто увидев про "Прошло три года, и к 2002" у меня первая мысль: ну делайте расчёт от начала года

[atues]

Засада с таблицей остатков слегка прикопана ) Да, остатки счетов ведутся по дням. После специальной процедуры "Открытие дня" остатки предыдущего дня фиксируются и становятся входящими остатками нового дня и т.д. Все бы ничего, но есть несколько ситуаций, которые эту простую схему портят:

1. Проводка сделана, но ошиблись суммой

2. Проводка сделана, но ошиблись счетом

3. Проводка вообще не нужна и ее надо удалить

Пока все это случается в текущем дне - ничего как бы и страшного. Но все резко усложняется, если надо что-то сделать в уже прошедшей дате, для которой остатки ранее были зафиксированы и трогать их по идее как бы и нельзя. Нельзя, да надо (все банки так делают, а кто говорит, что не делает - бесстыдные лжецы). В чем проблема? А вот в чем.

Пусть текущая дата: 2026-08-12. Надо исправить сумму по какой-то проводке в архиве: 2026-07-01. Исправляем? Да! Но после этого нужно пересчитать ВСЕ остатки по счетам, участвовавшим в проводке, между этими датами. Вот она - засада ))) Понятно, что это как бы просто арифметика, но возможностей накосячить здесь более чем достаточно.

А вот с таблицей проводок, без фиксации остатков, все делается элементарно и возможностей ошибиться на порядки меньше. Так что, не покупайтесь на остатки - они только с виду пушистые, а на деле зверюги те еще )

[ggo]

беда ж не в триггерах как таковых, беда ж в дублировании логики в разных местах.

[Timur555]

совершенно верно.

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