Excel och skalbarhet

Skalbarhet är en applikations förmåga att utvecklas flexibelt för att möta krav på tillväxt och komplexitet. I Excel-sammanhang avser skalbarhet Excels förmåga att hantera ständigt ökande datamängder.

De flesta Excel-fans är snabba med att påpeka att från och med Excel 2007 kan du placera 1 048 576 rader med data i ett enda Excel-kalkylblad - en överväldigande ökning från begränsningen på 65 536 rader som tidigare versioner av Excel har infört. Denna kapacitetsökning löser dock inte alla skalbarhetsproblem som översvämmer Excel.

Föreställ dig att du arbetar i ett litet företag och använder Excel för att analysera dess dagliga transaktioner. Allt eftersom tiden går bygger du en robust process komplett med alla formler, pivottabeller och makron du behöver för att analysera data som lagras i ditt välskötta kalkylblad.

När mängden data växer kommer du först att märka prestandaproblem. Kalkylarket blir långsamt att ladda och sedan långsamt att beräkna.

Varför händer detta? Det har att göra med hur Excel hanterar minne. När en Excel-fil laddas laddas hela filen in i RAM-minnet. Excel gör detta för att möjliggöra snabb databearbetning och åtkomst. Nackdelen med detta beteende är att varje gång data i ditt kalkylblad ändras måste Excel ladda om hela dokumentet till RAM. Nettoresultatet i ett stort kalkylblad är att det krävs mycket RAM-minne för att bearbeta även den minsta förändringen. Så småningom föregås varje åtgärd du gör i det gigantiska arbetsbladet av en plågsam väntan.

Dina pivottabeller kommer att kräva större pivotcacher, vilket nästan fördubblar Excel-arbetsbokens filstorlek. Så småningom kommer arbetsboken att bli för stor för att lätt kunna distribueras. Du kan till och med överväga att dela upp arbetsboken i mindre arbetsböcker (möjligen en för varje region). Detta får dig att duplicera ditt arbete.

Med tiden kan du så småningom nå gränsen på 1 048 576 rader i kalkylbladet. Vad händer då? Startar du ett nytt arbetsblad? Hur analyserar man två datamängder på två olika kalkylblad som en enhet? Är dina formler fortfarande bra? Måste du skriva nya makron?

Dessa är alla frågor som måste åtgärdas.

Naturligtvis kommer du också att möta Excel-kraftkunderna, som kommer att hitta olika smarta sätt att kringgå dessa begränsningar. Men i slutändan kommer dessa metoder alltid att vara helt enkelt lösningar. Så småningom kommer även dessa kraftkunder att börja tänka mindre på det mest effektiva sättet att utföra och presentera analys av sina data och mer på hur man får data att "passa" in i Excel utan att bryta mot deras formler och funktioner.

Excel är tillräckligt flexibelt för att en skicklig kund kan få det mesta att passa bra. Men när kunder bara tänker i termer av Excel, begränsar de sig utan tvekan, om än på ett otroligt funktionellt sätt.

Dessutom tvingar dessa kapacitetsbegränsningar ofta Excel-kunder att ha data förberedda för dem. Det vill säga att någon annan extraherar stora bitar av data från en stor databas och sedan aggregerar och formar data för användning i Excel.

Ska den seriösa analytikern alltid vara beroende av någon annan för sina databehov? Tänk om en analytiker kunde ges verktygen att komma åt stora mängder data utan att vara beroende av andra för att tillhandahålla data? Kan den analytikern vara mer värdefull för organisationen? Kunde den analytikern fokusera på analysens noggrannhet och kvaliteten på presentationen istället för att dirigera Excel-dataunderhåll?

Ett relationsdatabassystem (som Access eller SQL Server) är ett logiskt nästa steg för analytikern som står inför en ständigt ökande datapool. Databassystem har vanligtvis inte prestandaimplikationer med stora mängder lagrad data och är byggda för att hantera stora datamängder. En analytiker kan sedan hantera större datamängder utan att kräva att data sammanfattas eller förbereds för att passa in i Excel.

Dessutom, om en process någonsin blir mer avgörande för organisationen och behöver spåras i en mer företagsacceptabel miljö, kommer det att bli lättare att uppgradera och skala upp om den processen redan finns i ett relationsdatabassystem.