Kalkylark – Excel, Google Sheets eller ett ark med något annat namn – är riktigt coola och kraftfulla verktyg. Men det är databaserna också. När ska man hålla sig till ett kalkylblad? När ska du flytta upp till en databas?
Du kan använda kalkylblad och databaser för liknande ändamål. Med tanke på att både organiserar data och underlättar rapportering kan det ibland vara svårt att avgöra vilken som är bäst att använda. Så låt oss prata om för- och nackdelarna med varje alternativ.
I början...
Om du precis har börjat i affärer är ett kalkylblad (eller ett "ark") nästan alltid ditt förstahandsval. Nystartade företag har sällan budget för att stödja en skräddarsydd databas. Och dessutom är ditt företag nytt; du har ingen aning om det kommer att förbli litet, bli ett stort företag eller vara någonstans i mitten.
En annan faktor är att ditt företags struktur och organisation sannolikt kommer att förändras när det växer. Så egentligen är att bygga en databas i början inte ett vanligt alternativ. Det är där ark vanligtvis hoppar in.
Det viktigaste skälet till att använda ark är att de finns tillgängliga. Du kan börja använda Microsoft Excel, Google Sheets eller något annat kalkylarksprogram med bara några klick. Du behöver inte planera en komplicerad struktur; du kan helt enkelt ange dina data, göra beräkningar och rapporter och dela informationen med kollegor. Ark erbjuder många coola inbyggda funktioner och de kan se ett litet företag igenom ett bra tag.
Så låt oss säga att du har alla dina data på ark. Varför bör du överväga att bygga en databas? Med andra ord, varför komplicera ditt liv om allt fungerar?
Vid det här laget skulle jag föreslå att du frågar dig själv hur bra allt fungerar. Kom ihåg att allt fungerar bra tills det slutar fungera. När det gäller ark, ju mer data du har, desto fler problem kan du stöta på. Hur hjälper databaser dig att undvika dessa problem? Och när bör du överväga att byta?
Använda kalkylblad för att organisera data
Låt oss anta att vi har startat ett företag som tillhandahåller telekommunikation och internettjänster till kunder. Vi måste spåra vilken kund som för närvarande prenumererar på vilken tjänst. Kunder kan ha mer än en aktiv tjänst åt gången, och tjänsten kan löpa ut vid slutet av en viss period eller förnyas automatiskt.
Låt oss ta en titt på en lösning som använder ark.
Vi har helt enkelt gjort en lista över all data vi har, det vill säga det finns en mix av data på ett ställe. Vi har kunddata (kolumn A till E), tjänstetyper (kolumn F) och servicedetaljer (kolumner G, H och J).
Vid första anblicken ser allt ganska bra ut. Vi kan se all data utan att utföra några komplicerade åtgärder. Vi kan filtrera den data vi behöver och skapa pivottabeller eller grafer för rapporteringsändamål. Så långt har det gått bra.
Men om vi fortsätter att använda lakan när vi får fler kunder kan vi nå en punkt när allt blir för stort för att arken ska klara sig. Och detta medför en ny uppsättning problem.
Möjliga problem med kalkylblad
Jämfört med kalkylblad är databaser komplicerade. Men dessa "komplikationer" tjänar ett användbart syfte; de förhindrar eller åtminstone minimerar följande problem:
Datakvalitet
Datakvalitet och konsistens är ett stort problem för större ark. Även om vi avser att lagra data korrekt, problem med datakvalitet är mycket vanliga. Människor gör misstag, eller så har vi oväntad information att ange. Tänk bara på hur for-scenarierna nedan kan utgöra ett problem:
- Vi vill lägga till en ny kund utan att ange deras tjänstetyp. Ska vi lägga till kundinformationen och utelämna serviceinformationen? Om vi bara kan infoga kunder som har servicedetaljer är det en infogningsavvikelse .
- Vad händer om vi lägger till tjänstdata när den blir tillgänglig efter att ha skapat kundposten?
- Vad händer om en kund prenumererar på flera tjänster? Ska vi skapa en ny post för varje tjänst, eftersom vi bara kan ha en tjänsttyp per post?
- Vad händer om vi har flera poster för en kund och vi behöver uppdatera kundens information? Såvida vi inte ändrar informationen i alla relevanta rader kommer våra data att vara inkonsekventa. Vi kan ha två olika adresser för samma konto; i det fallet, hur kan vi veta vilka uppgifter som är korrekta?
- Vad händer när vi raderar data? Om vi raderar hela raden förlorar vi all den kundens data. Detta är ingen bra idé; det är bättre att bara ta bort deras tjänstdata och behålla deras kunddata. Men hur kan vi göra det om allt är lagrat på en rad?
- Vad händer om bara en kund prenumererar på en tjänst och vi tar bort posten? Om vi raderar kundens register, raderar vi också alla uppgifter om den tjänsten? (Detta kallas en raderingsavvikelse .) Betyder det att vi inte erbjuder den tjänsten längre? Om vi fortfarande erbjuder det har vi förlorat alla parametrar relaterade till den tjänsten.
Uppenbarligen kommer det att finnas komplikationer med att lagra data för alla företag. Vi har alla tagit emot problem med datakvaliteten – t.ex. fått räkningar för tjänster vi inte beställt, blivit debiterade två gånger för samma sak eller fått ett paket skickat till fel adress. Dessa saker händer, och på en liten datauppsättning är det relativt enkelt att fixa dem. Men vad händer när vi har tusentals eller till och med miljontals rader? Vi kommer snart att ägna nästan all vår tid åt att åtgärda dessa problem.
Prestandaproblem
Prestandaproblem hända när datauppsättningar blir för stora för att ett ark ska kunna hanteras effektivt. Du kommer att uppleva problem med datakvalitet mycket tidigare än prestandaproblem, men det betyder inte att prestandaproblem är oviktiga. Au contraire; prestandaproblem kan vara ännu farligare än problem med datakvalitet.
Det är vanligt att söka efter specifika rader, infoga nya rader, uppdatera eller ta bort cellvärden i befintliga rader och ta bort hela rader. Alla dessa åtgärder kräver mycket filtrering, vilket inte är några problem på en liten datamängd. Men när dina ark blir riktigt stora kan även en enkel operation ta några minuter. Att spendera hälften av din arbetsdag i väntan på att filtret ska göra sitt är knappast ett klokt val.
Det finns också det relaterade problemet med redundans – att lagra samma data flera gånger på disken (t.ex. kunddata lagras om och om igen i flera rader). Detta kommer också att ha en inverkan på prestandan.
På anständig hårdvara kommer ark med tusentals rader att vara okej. Men när du hamnar i tiotusentals rader, kan prestationsproblem leda till fula huvuden. Naturligtvis kommer ark med hundratusentals eller till och med miljoner rader att ha extremt dålig prestanda.
Å andra sidan finns databaser här för att lösa prestandaproblem. När allt är korrekt inställt kommer det inte att innebära några utmaningar att arbeta med miljontals rader.
Hantera historiska data och rapporter
Ett annat viktigt problem med ark är att spåra dataförändringar över tid. Om du bara tar bort data från ark förlorar du den. Om du bestämmer dig för att lagra ett dagligt ark (för att fånga alla ändringar och bevara historiska data), kommer du snart att begravas under massor av ark. Att skapa rapporter från en sådan struktur är verkligen tidskrävande, och kvaliteten på alla rapporter som genereras från den skulle vara mycket tveksam.
Upplever du sådana problem med dina uppgifter?
I dagens artikel har vi diskuterat några nackdelar med att använda ark för att organisera massor av data. Har du någonsin upplevt något av dessa problem? Är du redo att ta ditt företag till nästa nivå? Om svaret är "ja" är du på rätt plats! Nästa vecka kommer vi att lära oss hur en databas löser problem med att lagra data i ark.