Engedtessék meg egy másik vélemény is a témában amely árnyalja azokat a "tényeket", miszerint "köteles kijavítani a pénzért eladott, hibás elgondolása mentén írt programját" illetve BMW-s indexelés a hiba oka.
Ritkán de én is belefutok olyan igényekbe, amelyek arra építenek, hogy a számítógépek biztosan gyorsak és nagyon gyorsak. És mivel minden adat ott van, ezeket gyorsan ki lehet nyerni. Igen, gyorsan ki lehet nyerni, kockás füzettel 1 hónap lenne 4 embernek (+hiba), SQL által 4 óra. Ezeket lehetne persze másképp tervezni, felkészíteni ezekre az esetekre, de ha nem egyedi szoftvert írsz, akkor tudod 1m Ft alatt adni, cserébe nem 100%-ban a cégre lesz felkészítve.
De hozok egy példát is, amely az ügyfelek számára "triviális", a valóságban az adatok _messze vannak_ logikailag, ezért kijön az eredmény, egy SQL-be belefér, de nem 50ms a futásideje: "Elmúlt negyedév kimenő számláihoz rakjuk oda a bevételi oldal árát, hogy a haszonkulcs látható legyen". A feladat pontosítva úgy néz ki, hogy a kimenő számla dátuma (nem fontos hogy számal kelte vagy teljesítés, egyszerűsítsünk) előtti utolsó nagy beszerzés (mennyiség több mint 100, azaz nem 1-2db), ami nem raktárak között mozgott, hanem szállítólevél volt árát tegyük mellé. Ha az egy szállítólevél volt, akkor persze a számlán szereplő végső összeget jelenítsük meg. Ha visszáru volt, akkor az sem játszik, mert a selejt raktárba megy. Ez akárhogy is nézzük a negyedév 1m számlatételéhez 1m subquery lesz, mert nincs semmilyen fix kapcsolat a bejövő és kimenő konkrét mennyiségek között. Folyamatos FIFO számítás van, de nem pont azt a párosítást adja, amit az ügyfél kért. Excelbe hamarabb mellérakom és FKERES-sel megtalálom (igazából nem), de ezek SQL-ben messzi adatok.
Ügyfeleknek mindig szoktak példát mondani, hogy megértsék, erre a fentire pl: Az OTP régióvezetője azt kéri, hogy az elmúlt egy hónap összes tranzakciójához rakjuk hozzá, hogy akkor abban a fiókban mennyi összeg állt rendelkezésre, kimutatva azt, hogy nem volt-e valahol túlfogyás vagy túlkészletezés. Ez 1m tranzakciónál egy erős subquery lesz! Bármilyen aggregátummal (napi pénzkészlet külön táblában /nap/fiók/deviza) nem állja meg a helyét, mert a 11h-s tranzakciónál már nem a reggeli kezdő összeg játszik. "De hát ott van minden adat Forintban, csak ki kell számolni..." szokott lenni a válasz.
Régen OLAP kockák voltak nagy, lassan lefutó, több szempontból analizálandó adathalmazokra. Mostanság éjjel lefutó és perzisztensen eltárolt összesítéseket szeretünk javasolni. Reggelre megvan, ha 1-3 hónap kell egyben, akkor sem nagysárendileg sem jellegét tekintve nem fog hiányozni belőle a ma reggel 9-11.30-ig keletkezett tranzakciók.