Skaalautuvuus on sovelluksen kykyä kehittyä joustavasti kasvu- ja monimutkaisuusvaatimusten mukaisesti. Excelin yhteydessä skaalautuvuus viittaa Excelin kykyyn käsitellä jatkuvasti kasvavia tietomääriä.
Useimmat Excelin harrastajat huomauttavat nopeasti, että Excel 2007:stä lähtien voit sijoittaa 1 048 576 riviä tietoja yhdelle Excel-laskentataulukolle – tämä on valtava lisäys Excelin aiempien versioiden määräämästä 65 536 rivin rajoituksesta. Tämä kapasiteetin lisäys ei kuitenkaan ratkaise kaikkia Excelin skaalautuvuusongelmia.
Kuvittele, että työskentelet pienessä yrityksessä ja analysoit sen päivittäisiä tapahtumia Excelillä. Ajan myötä rakennat vankan prosessin, joka sisältää kaikki kaavat, pivot-taulukot ja makrot, joita tarvitset, jotta voit analysoida siististi ylläpidetylle laskentataulukollesi tallennettuja tietoja.
Tietojen määrän kasvaessa huomaat ensin suorituskykyongelmia. Laskentataulukon latautuminen hidastuu ja laskeminen hidastuu.
Miksi näin tapahtuu? Se liittyy tapaan, jolla Excel käsittelee muistia. Kun Excel-tiedosto ladataan, koko tiedosto ladataan RAM-muistiin. Excel tekee tämän mahdollistaakseen nopean tietojenkäsittelyn ja pääsyn. Tämän toiminnan haittana on, että aina kun laskentataulukon tiedot muuttuvat, Excelin on ladattava koko asiakirja uudelleen RAM-muistiin. Nettotulos suuressa laskentataulukossa on, että pienimmänkin muutoksen käsittely vaatii paljon RAM-muistia. Lopulta jokaista jättimäisellä työarkilla tekemääsi toimintaa edeltää tuskallinen odotus.
Pivot-taulukot vaativat suurempia pivot-välimuistia, mikä lähes kaksinkertaistaa Excel-työkirjan tiedostokoon. Lopulta työkirjasta tulee liian suuri levitettäväksi helposti. Voit jopa harkita työkirjan jakamista pienempiin työkirjoihin (mahdollisesti yksi kullekin alueelle). Tämä saa sinut kopioimaan työsi.
Ajan myötä saatat saavuttaa laskentataulukon 1 048 576 rivin rajan. Mitä sitten tapahtuu? Aloitatko uuden laskentataulukon? Kuinka analysoit kahta tietojoukkoa kahdella eri laskentataulukolla yhtenä kokonaisuutena? Ovatko kaavosi edelleen hyvät? Pitääkö sinun kirjoittaa uusia makroja?
Nämä kaikki ovat asioita, joihin on puututtava.
Tietenkin kohtaat myös Excelin tehoasiakkaita, jotka löytävät erilaisia älykkäitä tapoja kiertää nämä rajoitukset. Lopulta nämä menetelmät ovat kuitenkin aina vain kiertotapoja. Lopulta jopa nämä tehoasiakkaat alkavat miettiä vähemmän tehokkainta tapaa suorittaa ja esittää tietojen analysointi ja enemmän sitä, kuinka tiedot saadaan "sopimaan" Exceliin rikkomatta kaavoja ja toimintoja.
Excel on riittävän joustava, jotta taitava asiakas voi saada useimmat asiat sopivaksi. Kuitenkin, kun asiakkaat ajattelevat vain Excelissä, he epäilemättä rajoittavat itseään, vaikkakin uskomattoman toimivalla tavalla.
Lisäksi nämä kapasiteettirajoitukset pakottavat usein Excel-asiakkaat valmistelemaan tiedot heille. Toisin sanoen joku muu poimii suuria tietopaloja suuresta tietokannasta ja sitten kokoaa ja muotoilee tiedot käytettäväksi Excelissä.
Pitäisikö vakavan analyytikon tietotarpeissaan aina olla riippuvainen jostain muusta? Entä jos analyytikolle annettaisiin työkalut päästä käsiksi valtaviin tietomääriin ilman, että hän olisi riippuvainen muiden tietojen toimittamisesta? Voisiko tuo analyytikko olla arvokkaampi organisaatiolle? Voisiko tuo analyytikko keskittyä analyysin tarkkuuteen ja esityksen laatuun sen sijaan, että reitittäisi Excel-tietojen ylläpitoa?
Relaatiotietokantajärjestelmä (kuten Access tai SQL Server) on looginen seuraava askel analyytikolle, joka kohtaa jatkuvasti kasvavan tietopankin. Tietokantajärjestelmillä ei yleensä ole suorituskykyvaikutuksia suurien tallennettujen tietomäärien kanssa, ja ne on rakennettu käsittelemään suuria tietomääriä. Analyytikko voi sitten käsitellä suurempia tietojoukkoja ilman, että tiedoista on tehtävä yhteenvetoa tai valmistella sopimaan Exceliin.
Lisäksi, jos prosessista tulee koskaan tärkeämpi organisaatiolle ja sitä on seurattava yrityksen kannalta paremmin hyväksyttävässä ympäristössä, on helpompi päivittää ja laajentaa, jos prosessi on jo relaatiotietokantajärjestelmässä.