Skaleeritavus on rakenduse võime paindlikult areneda, et vastata kasvu ja keerukuse nõuetele. Exceli kontekstis viitab skaleeritavus Exceli võimele käsitleda üha kasvavaid andmemahtusid.
Enamik Exceli austajaid märgib kiiresti, et Excel 2007 seisuga saate ühele Exceli töölehele paigutada 1 048 576 rida andmeid – see on tohutu kasv võrreldes Exceli eelmiste versioonide kehtestatud 65 536 rea piiranguga. See mahu suurendamine ei lahenda aga kõiki Exceli mastaapsuse probleeme.
Kujutage ette, et töötate väikeses ettevõttes ja kasutate selle igapäevaste tehingute analüüsimiseks Excelit. Aja möödudes loote tugeva protsessi koos kõigi valemite, liigendtabelite ja makrodega, mida vajate, et analüüsida teie korralikult hooldatud töölehel salvestatud andmeid.
Andmete hulga kasvades märkate esmalt jõudlusprobleeme. Arvutustabeli laadimine muutub aeglaseks ja seejärel arvutamine aeglaseks.
Miks see juhtub? See on seotud sellega, kuidas Excel mälu käsitleb. Exceli faili laadimisel laaditakse kogu fail RAM-i. Excel teeb seda andmete kiireks töötlemiseks ja juurdepääsuks. Selle käitumise puuduseks on see, et iga kord, kui teie arvutustabeli andmed muutuvad, peab Excel kogu dokumendi RAM-i uuesti laadima. Suure arvutustabeli tulemuseks on see, et isegi väikseima muudatuse töötlemiseks kulub palju RAM-i. Lõpuks eelneb igale hiiglaslikul töölehel tehtud tegevusele piinav ootamine.
Teie pivot-tabelid nõuavad suuremat pöördevahemälu, mis peaaegu kahekordistab Exceli töövihiku failimahu. Lõpuks muutub töövihik lihtsalt levitamiseks liiga suureks. Võite isegi kaaluda töövihiku jagamist väiksemateks töövihikuteks (võib-olla üks iga piirkonna jaoks). See põhjustab teie töö dubleerimist.
Aja jooksul võite jõuda töölehe 1 048 576 rea piirini. Mis siis saab? Kas alustate uue töölehega? Kuidas analüüsida kahte andmestikku kahel erineval töölehel ühe olemina? Kas teie valemid on ikka head? Kas peate kirjutama uusi makrosid?
Need on kõik probleemid, millega tuleb tegeleda.
Loomulikult puutute kokku ka Exceli klientidega, kes leiavad erinevaid nutikaid viise nende piirangute ületamiseks. Lõpuks on need meetodid siiski alati lihtsalt lahendused. Lõpuks hakkavad isegi need võimsad kliendid vähem mõtlema sellele, milline on kõige tõhusam viis oma andmete analüüsi teostamiseks ja esitamiseks, ja rohkem sellele, kuidas muuta andmed Excelisse "mahtuma" ilma valemeid ja funktsioone rikkumata.
Excel on piisavalt paindlik, et asjatundlik klient suudab enamiku asjadest täpselt sobitada. Ent kui kliendid mõtlevad ainult Excelile, piiravad nad end kahtlemata, ehkki uskumatult funktsionaalsel viisil.
Lisaks sunnivad need mahupiirangud sageli Exceli kliente nende jaoks andmeid ette valmistama. See tähendab, et keegi teine ekstraheerib suurest andmebaasist suuri andmeid ning seejärel koondab ja kujundab andmed Excelis kasutamiseks.
Kas tõsine analüütik peaks oma andmevajaduste osas alati sõltuma kellestki teisest? Mis siis, kui analüütikule saaks anda vahendid, et pääseda juurde suurele hulgale andmetele, ilma et ta peaks andmete esitamisel sõltuma teistest? Kas see analüütik võiks olla organisatsiooni jaoks väärtuslikum? Kas see analüütik võiks Exceli andmete hoolduse suunamise asemel keskenduda analüüsi täpsusele ja esitluse kvaliteedile?
Relatsiooniline andmebaasisüsteem (nagu Access või SQL Server) on loogiline järgmine samm analüütikule, kes seisab silmitsi üha suureneva andmekogumiga. Andmebaasisüsteemidel ei ole tavaliselt suure salvestatud andmehulga puhul tulemuslikkust ja need on loodud suurte andmemahtude käsitlemiseks. Analüütik saab seejärel käsitleda suuremaid andmekogumeid, ilma et oleks vaja andmetest kokkuvõtet teha või Excelisse mahtumiseks ette valmistada.
Samuti, kui protsess muutub kunagi organisatsiooni jaoks olulisemaks ja seda tuleb jälgida ettevõtte jaoks vastuvõetavamas keskkonnas, on seda lihtsam uuendada ja laiendada, kui see protsess on juba relatsioonilises andmebaasisüsteemis.