Kuidas arvutada konto väljavõtet kuupäevast kuupäevani?

.. selgus et üsna tihti muudetakse vanu tehinguid ..

See ongi probleem, mis tuleb lahendada.

Ma ei ole kunagi näinud raamatupidajat kustutuskummiga päevaraamatu kallal toimetamas. Rmp printsiibid on paika loksunud juba ammu enne arvutite leiutamist ja seal on omad põhjused. See, et andmebaasis on lihtne UPDATE päringuid teha ei muuda asja.

Rusikareegel: sisestatud tehingud on "kivisse raiutud" nende majanduslikku sisu puudutavas osas. Ehk siis mingeid tehnilisi meta-andmeid võib muuta, aga näiteks tehingusumma on fikseeritud.

Osad väidavad, et on ka tehinguid millel puudub majanduslik sisu - näiteks eksikombel sisestatud andmeid. Ma seda erisust ei näe - raamatupidamise rakendus peab suvalisel ajahetkel kõik "ausalt ära rääkima", kui keegi sisestas mingit jama, siis see on ümberlükkamatu fakt. Kui see jama ei oma majanduslikku sisu selle sisestaja jaoks, on tihti mõistlik eeldada, et mingi teine osapool on nende andmetega juba "toimetanud".

Kaasus 1. Imporditud 3000 rida on täielik jama?

Sisestada miinusmärgiga kanne "3000 rea tühistamine" Importida uuesti

Kaasus 2. Keegi tahab muuta tehingusummat.

Stop! Sellist võimalust ei ole ju olemas!? Kaks varianti:

1. Täiendav kanne (+/-)
2. Tühistuskanne & uus kanne

Täiesti eraldi küsimus on juba see, et rakendusega töötavad inimesed ei taha igapäevaselt näiteks neid tuhandeid vigaselt imporditud ridu vahtida. See aga ei eelda seda, et me need read andmebaasist peaks minema pühkima. Või "muudetud" arved andmebaasis reaalselt ära muutma. Küsimus on puhtalt vaate tasandil - saraselt näiteks kedagi ei huvita üldse laekumised või keegi töötab ainult mingi konkreetse kliendiga. Tõenäoliselt peab iga rmp süsteem olema nagunii suuteline selliseid väljavõtteid koostama (koos vastavate alg- ja lõppsaldodega).

Teise variandi puhul näen ma seda probleemi, et kuna seda hetkesaldot pidevalt muudetakse, siis on sel kõrgendatud risk kuidagi viga saada. Ja kui kõik ülejäänud saldod sellest hetkesaldost sõltuvad, siis nii kui hetkesaldoga midagigi juhtub, on koheselt vigased ka kõik ülejäänud saldod.

Kui aga pöörata asi vastupidiseks ja lähtuda mitte lõpp- vaid algsaldost, siis taolist probleemi pole, kuna algsaldot pea kunagi ei muudeta (või on see hoopistükkis alati nullis).

Muidugi pole algusest saadik arvutamine kuigi effektiivne, seega pöörduksin ma su esimese idee suunas. Kuid vaheseisude salvestamine peaks toimuma mitte nädala, kuu või aasta kaupa, vaid teatude tehingute arvu kaupa - näiteks peale igat sajandat tehingut - nõndaviisi ei sõltu asjad sellest, kas kuus juhtutakse tegema 5 või 5000 tehingut.

Ning lõpuks võib olla effektiivsuse mõttes kasulik hoida meeles ka toda hetkesaldot, kuid nüüd ei sõltuks sellest enam kõik mustmiljon kunagi tehtud tehingut vaid maksimaalselt viimased sada.

Kui üldistada iga N kande kaupa summeerimist, siis võiks hoopis hoida kannete summasid kahendpuuna -

• iga kande juurde salvestame selle kande enda summa
• iga teise kande juurde summeerime eelmise kande
• iga neljanda juurde summeerime jooksva ja eelmise paari (mis on juba kokku liidetud)
• iga kaheksanda juurde kahe viimase neliku summa (mille saame juba olemasolevast nelikust ja paarist)

Sellisel juhul on suvalisele kandele vastava saldo leidmiseks vaja log(n) osasummat kokku liita, sama kallis ka kande väärtuse muutmine ja uue kande lõppu lisamine

Mulle meeldib originaalne lahendus kus iga tehingu juures on ka saldo. Ma oletan, et probleem tekib situatsioonis kus keegi muudab andmeid 200 kannet tagasi ja nüüd on vaja kõik need kanded ümber arvutada. Edasi ma oletan et hetkel on see realiseeritud tsükliga üle vastavate kannete ning iga ümberarvutatud kirje kohta tehakse kirjele UPDATE. Ja kui mitu kasutajat teeb sarnast operatsiooni sama tabeli kallal, siis tekib meil "pudelikael".

Pakun välja, et seda operatsiooni saab andmebaasi tasemel optimiseerida ja pudelikaela vältida. Lahenduse sisuks oleks kasutada nn BULK UPDATE ehk siis teha ainult üks UPDATE nende 200 kirje uuendamiseks mis tuli ümber arvutada.

Realiseerida saaks seda mitut moodi. Üheks lahenduseks oleks kopeerida need 200 rida kõigepealt TEMPORARY tabelisse ja teha seal ümberarvutused ning siis uuendada tulemused tagasi põhitabelisse ühe UPDATE abi:

update tbl_kontod tk
inner join tbl_tmp tt on (tk.id = tt.id)
set tk.konto = tt.konto, tk.j22k = tt.j22k;

Kuna Postgresql toetab massiive (arrays), siis veelgi efektiivsem on kasutada funktsiooni, mis teostab ümberarvutused massiivides ja tagastab siis tulemuse multidimensionaalse massiivina, mida siis UPDATE lauses saaks kasutada TBL_TMP asemel. Oracle andmebaasis oleks seda näiteks suht lihtne teha, kuid küllap on miskitmoodi tehtav ka Postgres.

Tulemus peaks olema see, et andmebaasi jõudlus ei pudelikaela ei teki isegi kui mõnel kasutajal peaks olema vaja teostada mitme tuhande kande ümberarvutus.

Täiendavalt võib muidugi kaaluda, et ehk annab kogu 200 kande kontojäägid ühe SQL-iga ära uuendada:

update tbl_kontod set j22k = j22k + p_muudatus
where konto_nimi = p_konto_nimi and kande_aeg >= p_muudatuse_aeg;

sisuliselt ei ole see ju nagu tavaline konto ja saldo vaid ikkagi mingi aretis. Tavalisel konteerimisel on ka kõik muudatused uued read (vastavalt + või - ridadena) ja ajalugu otseselt ei mõjuta ja sellisel juhul oleks mõistlik hoida iga rea juures tõesti eelmise tehingu saldot (hetkesaldo võrduks eelmine saldo + hetke konteering) ning siis oleks suvalises ajalises päringus teada (iga rea kohta) eelnev ja lõppsaldo