Скалабилност је способност апликације да се флексибилно развија како би испунила захтеве раста и сложености. У контексту Екцел-а, скалабилност се односи на Екцел-ову способност да рукује све већим количинама података.
Већина љубитеља Екцел-а брзо истиче да од Екцел-а 2007 можете да ставите 1.048.576 редова података у један Екцел радни лист — огромно повећање у односу на ограничење од 65.536 редова које су наметнуле претходне верзије Екцел-а. Међутим, ово повећање капацитета не решава све проблеме скалабилности који преплављују Екцел.
Замислите да радите у малој компанији и користите Екцел за анализу њених дневних трансакција. Како време пролази, градите робустан процес са свим формулама, заокретним табелама и макроима који су вам потребни да бисте анализирали податке који су ускладиштени у вашем уредно одржаваном радном листу.
Како количина података расте, прво ћете приметити проблеме са перформансама. Табела ће се споро учитавати, а затим споро рачунати.
Зашто се то дешава? То има везе са начином на који Екцел рукује меморијом. Када се учита Екцел датотека, цела датотека се учитава у РАМ. Екцел то чини како би омогућио брзу обраду података и приступ. Недостатак оваквог понашања је што сваки пут када се подаци у вашој табели промене, Екцел мора поново да учита цео документ у РАМ. Нето резултат велике табеле је да је потребна велика количина РАМ-а за обраду чак и најмањих промена. На крају, свакој радњи коју предузмете у огромном радном листу претходи мучно чекање.
Ваше заокретне табеле ће захтевати веће кеш меморије, што ће скоро удвостручити величину датотеке Екцел радне свеске. На крају ће радна свеска постати превелика да би се лако дистрибуирала. Можда чак размислите о разбијању радне свеске на мање радне свеске (могуће по једну за сваки регион). То доводи до тога да дуплирате свој рад.
Временом ћете можда на крају достићи ограничење од 1.048.576 редова радног листа. Шта се онда дешава? Да ли започињете нови радни лист? Како анализирате два скупа података на два различита радна листа као један ентитет? Да ли су ваше формуле још увек добре? Да ли ћете морати да пишете нове макрое?
Све су то питања која треба решити.
Наравно, такође ћете се сусрести са клијентима који користе Екцел, који ће пронаћи разне паметне начине да заобиђу ова ограничења. На крају, међутим, ове методе ће увек бити једноставно решење. На крају, чак и ови искусни купци ће почети мање да размишљају о најефикаснијем начину да изврше и представе анализу својих података, а више о томе како да податке „уклопе“ у Екцел без кршења њихових формула и функција.
Екцел је довољно флексибилан да искусан купац може да уклопи већину ствари. Међутим, када купци размишљају само у терминима Екцел-а, они се несумњиво ограничавају, иако на невероватно функционалан начин.
Поред тога, ова ограничења капацитета често приморавају кориснике Екцел-а да припреме податке за њих. Односно, неко други издваја велике комаде података из велике базе података, а затим агрегира и обликује податке за употребу у Екцел-у.
Да ли озбиљни аналитичар увек треба да зависи од неког другог за своје потребе података? Шта ако се аналитичару могу дати алати за приступ огромним количинама података, а да се не ослања на друге у пружању података? Може ли тај аналитичар бити вреднији за организацију? Да ли би се тај аналитичар могао фокусирати на тачност анализе и квалитет презентације уместо да усмерава одржавање Екцел података?
Систем релационих база података (као што је Аццесс или СКЛ Сервер) је логичан следећи корак за аналитичара који се суочава са све већим скупом података. Системи база података обично немају импликације на перформансе са великим количинама ускладиштених података и изграђени су да адресирају велике количине података. Аналитичар тада може да рукује већим скуповима података без потребе да се подаци сумирају или припреме да се уклопе у Екцел.
Такође, ако процес икада постане важнији за организацију и треба га пратити у окружењу које је прихватљивије за предузећа, биће лакше надоградити и повећати ако је тај процес већ у систему релационе базе података.