Egy lehetőség, hogy van a termék táblában egy aktuális mennyiség oszlop, és a mozgásoknak van egy másik táblája (termék, dátum, delta) oszlopokkal. Utóbbi táblából termék és dátum szerint csoportosítva, deltát összegezve kijönnek a napi mozgások, egy termék aktuális készlével összevetve pedig látod, hogy melyik nap mennyi volt a készlet (ezt már kódból számolnám, ha megvan a többi adat SQL-ből). Nem gondolom, hogy pár millió sor esetén ez kezelhetetlen lenne. De van az úgy, hogy a denormalizált adatszerkezet a célrevezető, és a mozgások táblában lenne egy oszlop a mozgás utáni aktuális készlettel. Csak arra kell figyelni, hogy ezek a megoldások lockolással járnak, viszont nem mondtad, hogy egetverő lenne az írások gyakorisága. A módszer előnye, hogy az élő táblában ott van minden adat, ami a lekérdezéshez kell.
Ha így lassú a query mert pl. szar a hardver, akkor a következő ötlet egy materialized view vagy hasonló (ezt hívod cache táblának, de az a lényeg, hogy egy jó RDBMS ezt adja neked ingyen, nem neked kell megírni). Ezt akár óránként vagy sűrűbben is lehet automatizáltan frissítgetni. Ha ez nem elég friss, akkor a view-ból kérdezed le a korábbi adatokat és melléteszed a view frissítése utáni változásokat (de ez csak akkor lesz jó, ha utóbbi halmazba kevés adat kerül).
Ilyen kis adatmennyiségnél én nem feltétlenül mennék bele bonyolultabb kódolásokba, memcached használatába vagy ilyesmi. De lenne ötletem arra is.