přepočítání zůstatků v pokladně na jeden příkaz

Pája:
Mám lepší nápad. Předělej databázi, protože ji máš špatně navrženou. Proto musíš vytvářet tak komplikované dotazy. Odstraň ty zůstatky a počítej je vždy až ve vývěru z databáze nebo ve scriptu který s daty pracuje. Taky to přečíslovávání řádků je zbytečná věc. Ze strany scriptu je jedno, jestli ta čísla jdou od jedničky nahoru bez jakékoli mezery nebo zda jsou náhodně na přeskáčku. A k ničemu jinému nejsou. Potřebuje jetnotlivé platby při výpisu číslovat od jedničky? Tak číslujte ale k tomu není potřeba nějaké idečko platby. To jsou dvě na sobě nezávislé věci.

Pája:
Tohle je každopádně špatně navržená aplikace a vkládání a přepočítávání řádků tímto způsobem je brutální násilí, které bych snad ani do aplikace nezapracovával a pokud k tomu někdy má dojít, řešil bych to pomocí jednorázového php cyklu.

Jak by to myslím šlo navrhnout líp: ke každé operaci bych neukládal výsledek, ale jen pohyb. Spočítat zůstatek lze pak pomocí jednoho nebo dvou SUM() podle způsobu řešení. A v prípadě, že se těch řádků má vyjet víc, spočítal bych to pro první vypsaný řádek pomocí těch dvou SUM() a pak pro každý další prostým sčítáním na úrovni php.

Doplním, že výpočet kumulativních sum není nic výjimečného a lze najít hotová řešení, např. stackoverflow.com/a/3144820 nebo stackoverflow.com/questions/2563918/create-a-cumulative-sum-column-in-mysql apod.

A já zas doplním, že počítat to pokaždé sice zátěž je, ovšem není to nic extrémního. Schválně jsem si vytvořil pseudoměření: Vytvořil jsem tabulku a naplnil ji milionem záznamů (resp 2^20) náhoných čísel v intervalu -1000 až +1000. Pak jsem změřil, jak dlouho trvá sečíst databázi těchto milion záznamů. Zrovna v mém případě to vyšlo 0.4s. Je to pseoudoměření jelikož do hry může a vstupuje spousta jiných faktorů, ale je vidět, že nic extrémnho to není. S milionem záznamů zvládne mysql obstojně pracovat. Vzhledem k odhadované úrovni tvých zkušeností si nemyslím, že tvůj projekt bude pracovat s databází s řádově vyšími počty záznamů. Spíše naopak. Pokud by tě ale přesto trápila ta zátěž, dá se to řešit. Ovšem ne tím způsobem o jaký se snažíš ty. Viděl bych to na kešování už vypočítaných výsledků. Tudíž třeba ta vygenerovaná html tabulka s daty by se uživateli nejen vypsala, ale zároveň by se ten vygenerovaný html kód uložil i na serveru. Příště by se už php script vůbec neptal databáze a rovnou jen vypsal ten uložený html kód. Samozřejmě je potřeba při změně v databázi promazat i keš aby se při příštím dotazu zobrazila čersvá data, vygeneroval a uložil nový kód. Výkon se tedy šetřit dá, jen se to provádí na jiných místech. A myslím že bude trvat ještě dost dlouho, než budeš muset zavést kešování.