Excel a škálovateľnosť

Škálovateľnosť je schopnosť aplikácie vyvíjať sa flexibilne, aby spĺňala požiadavky na rast a zložitosť. V kontexte Excelu sa škálovateľnosť týka schopnosti Excelu spracovať neustále sa zvyšujúce objemy údajov.

Väčšina nadšencov Excelu rýchlo poukazuje na to, že od Excelu 2007 môžete umiestniť 1 048 576 riadkov údajov do jedného excelového hárka – čo je obrovský nárast oproti obmedzeniu 65 536 riadkov, ktoré zaviedli predchádzajúce verzie Excelu. Toto zvýšenie kapacity však nerieši všetky problémy so škálovateľnosťou, ktoré zaplavujú Excel.

Predstavte si, že pracujete v malej spoločnosti a používate Excel na analýzu jej každodenných transakcií. Postupom času vytvárate robustný proces so všetkými vzorcami, kontingenčnými tabuľkami a makrami, ktoré potrebujete na analýzu údajov, ktoré sú uložené vo vašom prehľadne udržiavanom pracovnom hárku.

S rastúcim množstvom údajov si najskôr všimnete problémy s výkonom. Tabuľka sa bude pomaly načítavať a potom spomalí aj výpočet.

Prečo sa to deje? Súvisí to so spôsobom, akým Excel narába s pamäťou. Po načítaní súboru programu Excel sa celý súbor načíta do pamäte RAM. Excel to robí, aby umožnil rýchle spracovanie údajov a prístup. Nevýhodou tohto správania je, že zakaždým, keď sa údaje v tabuľke zmenia, Excel musí znova načítať celý dokument do pamäte RAM. Čistým výsledkom veľkej tabuľky je, že na spracovanie aj najmenšej zmeny je potrebné veľké množstvo pamäte RAM. Nakoniec každej akcii, ktorú vykonáte v obrovskom pracovnom hárku, predchádza mučivé čakanie.

Vaše kontingenčné tabuľky budú vyžadovať väčšie kontingenčné vyrovnávacie pamäte, čím sa takmer zdvojnásobí veľkosť súboru excelového zošita. Nakoniec bude zošit príliš veľký na to, aby sa dal ľahko distribuovať. Môžete dokonca zvážiť rozdelenie zošita na menšie zošity (možno jeden pre každý región). To spôsobí, že budete duplikovať svoju prácu.

Časom možno dosiahnete limit 1 048 576 riadkov pracovného hárka. čo sa stane potom? Začínate s novým pracovným listom? Ako analyzujete dva súbory údajov na dvoch rôznych pracovných hárkoch ako jednu entitu? Sú vaše vzorce stále dobré? Budete musieť písať nové makrá?

To všetko sú problémy, ktoré treba riešiť.

Samozrejme sa stretnete aj s výkonnými zákazníkmi Excelu, ktorí nájdu rôzne šikovné spôsoby, ako tieto obmedzenia obísť. V konečnom dôsledku však tieto metódy budú vždy len riešením. Nakoniec aj títo silní zákazníci začnú menej premýšľať o najefektívnejšom spôsobe vykonávania a prezentovania analýzy svojich údajov a viac o tom, ako údaje „zapadnúť“ do Excelu bez narušenia ich vzorcov a funkcií.

Excel je dostatočne flexibilný na to, aby skúsený zákazník dokázal väčšinu vecí prispôsobiť. Keď však zákazníci uvažujú iba v pojmoch Excel, nepochybne sa obmedzujú, aj keď neuveriteľne funkčným spôsobom.

Navyše, tieto kapacitné obmedzenia často nútia zákazníkov Excelu, aby si nechali dáta pripraviť. To znamená, že niekto iný extrahuje veľké kusy údajov z veľkej databázy a potom tieto údaje agreguje a tvaruje na použitie v Exceli.

Mala by byť seriózna analytička vždy závislá na niekom inom, pokiaľ ide o jej potreby údajov? Čo ak by analytik mohol dostať nástroje na prístup k obrovskému množstvu údajov bez toho, aby sa pri poskytovaní údajov spoliehal na iných? Mohol by byť tento analytik pre organizáciu cennejší? Mohol by sa tento analytik zamerať na presnosť analýzy a kvalitu prezentácie namiesto smerovania údržby údajov v Exceli?

Relačný databázový systém (ako je Access alebo SQL Server) je logickým ďalším krokom pre analytika, ktorý čelí neustále sa zväčšujúcemu dátovému fondu. Databázové systémy zvyčajne nemajú vplyv na výkon s veľkým množstvom uložených údajov a sú zostavené tak, aby riešili veľké objemy údajov. Analytik potom môže spracovať väčšie množiny údajov bez toho, aby vyžadoval zhrnutie alebo prípravu údajov, aby sa zmestili do Excelu.

Ak sa proces niekedy stane pre organizáciu dôležitejším a bude potrebné ho sledovať v prostredí prijateľnejšom pre podniky, bude jednoduchšie upgradovať a rozšíriť, ak je tento proces už v systéme relačnej databázy.