(Ja, ik voeg nog een toe antwoorden. Motivering:Het pakt het onderliggende probleem op een andere manier aan.)
Het onderliggende probleem lijkt te zijn dat er een steeds groter wordende "transactie"-tabel is waaruit verschillende statistieken zijn afgeleid, zoals SUM(amount) . De prestatie hiervan zal alleen maar slechter en slechter worden naarmate de tafel(s) groeien.
De basis voor dit antwoord is om op twee manieren naar de gegevens te kijken:"Geschiedenis" en "Huidige". Transactions is de Geschiedenis. Een nieuwe tabel is de Current totalen voor elke gebruiker. Maar ik zie meerdere manieren om dat te doen. Elk omvat een of andere vorm van subtotalen om te voorkomen dat 773K rijen worden toegevoegd om het antwoord te krijgen.
- De traditionele manier van bankieren... Tel elke nacht de
Transactionsvan de dag op en voeg ze toe aanCurrent. - De manier van materialiseren... Elke keer dat er een rij wordt toegevoegd aan
Transactions, verhoogCurrent. - Hybride:bewaar dagelijkse subtotalen in een 'overzichtstabel'. Tel die subtotalen bij elkaar op om de
SUM. te krijgen tot gisteravond.
Meer discussie in mijn blog op Samenvattingstabellen .
Merk op dat het up-to-the-second saldo voor de bank- of hybride manier een beetje lastig is:
- Ontvang het bedrag van gisteravond
- Voeg alle transacties toe die gedurende de dag hebben plaatsgevonden.
Elk van de benaderingen zal veel zijn sneller dan het scannen van alle 773K rijen voor de gebruiker, maar het zal complexere code zijn.