Regneark – Excel, Google Sheets eller et ark med et hvilket som helst andet navn – er virkelig seje og kraftfulde værktøjer. Men altså, det er databaser også. Hvornår skal du holde dig til et regneark? Hvornår skal du flytte op til en database?
Du kan bruge regneark og databaser til lignende formål. Da både organiserer data og letter rapportering, kan det til tider være svært at afgøre, hvilken der er den bedste at bruge. Så lad os tale om fordele og ulemper ved hver mulighed.
I begyndelsen...
Hvis du lige er startet i erhvervslivet, er et regneark (eller et "ark") næsten altid dit førstevalg. Startups har sjældent budgettet til at understøtte en skræddersyet database. Og desuden er din virksomhed ny; du har ingen idé om, om den forbliver lille, bliver en stor virksomhed eller et sted i midten.
En anden faktor er, at din virksomheds struktur og organisation sandsynligvis vil ændre sig, efterhånden som den vokser. Så egentlig er det ikke en almindelig mulighed at bygge en database i starten. Det er her, ark normalt hopper ind.
Den vigtigste grund til at bruge ark er, at de er tilgængelige. Du kan begynde at bruge Microsoft Excel, Google Sheets eller et hvilket som helst andet regnearksprogram med blot et par klik. Du behøver ikke at planlægge en kompliceret struktur; du kan blot indtaste dine data, lave beregninger og rapporter og dele oplysningerne med kolleger. Ark tilbyder mange smarte indbyggede muligheder, og de kan se en lille virksomhed igennem i et stykke tid.
Så lad os sige, at du har alle dine data på ark. Hvorfor bør du overveje at bygge en database? Med andre ord, hvorfor komplicere dit liv, hvis alt fungerer?
På dette tidspunkt vil jeg foreslå, at du spørger dig selv, hvor godt alt fungerer. Husk, alt fungerer ok, indtil det holder op med at virke. I tilfælde af ark, jo flere data du har, jo flere problemer kan du løbe ind i. Hvordan hjælper databaser dig med at undgå disse problemer? Og hvornår bør du overveje at skifte?
Brug af regneark til at organisere data
Lad os antage, at vi har startet en virksomhed, der leverer telekommunikation og internettjenester til kunder. Vi skal spore, hvilken kunde der i øjeblikket abonnerer på hvilken tjeneste. Kunder kan have mere end én aktiv tjeneste ad gangen, og tjenesten kan udløbe ved udgangen af en bestemt periode eller forny automatisk.
Lad os tage et kig på en løsning, der bruger ark.
Vi har simpelthen lavet en liste over alle de data vi har, det vil sige at der er en blanding af data ét sted. Vi har kundedata (kolonne A til E), servicetyper (kolonne F) og servicedetaljer (kolonne G, H og J).
Ved første øjekast ser alt ret godt ud. Vi kan se alle data uden at udføre komplekse handlinger. Vi kan filtrere de data, vi har brug for, og oprette pivottabeller eller grafer til rapporteringsformål. Så langt, så godt.
Men hvis vi fortsætter med at bruge ark, når vi får flere kunder, kan vi ramme et punkt, hvor alt bliver for stort til, at arkene kan klare det. Og dette medfører et nyt sæt problemer.
Potentielle problemer med regneark
Sammenlignet med regneark er databaser komplicerede. Men disse "komplikationer" tjener et nyttigt formål; de forhindrer eller i det mindste minimerer følgende problemer:
Datakvalitet
Datakvalitet og konsistens er et stort problem for større ark. Selvom vi har til hensigt at gemme data korrekt, er der datakvalitetsproblemer er meget almindelige. Folk laver fejl, eller vi har uventede oplysninger at indtaste. Tænk bare på, hvordan for scenarierne nedenfor kunne give et problem:
- Vi ønsker at tilføje en ny kunde uden at angive deres servicetype. Skal vi tilføje kundeoplysningerne og udelade serviceoplysningerne? Hvis vi kun kan indsætte kunder, der har serviceoplysninger, er det en indsæt anomali .
- Hvad hvis vi tilføjer servicedata, når de bliver tilgængelige efter oprettelse af kunderegistreringen?
- Hvad hvis en kunde abonnerer på flere tjenester? Skal vi oprette en ny post for hver tjeneste, da vi kun kan have én tjenestetype pr. post?
- Hvad hvis vi har flere registreringer for én kunde, og vi skal opdatere denne kundes oplysninger? Medmindre vi ændrer oplysningerne i alle de relevante rækker, vil vores data være inkonsekvente. Vi kunne have to forskellige adresser for den samme konto; hvordan kunne vi i den situation vide, hvilke data der er korrekte?
- Hvad sker der, når vi sletter data? Hvis vi sletter hele rækken, mister vi alle kundens data. Dette er ikke en god idé; det er bedre kun at fjerne deres servicedata og beholde deres kundedata. Men hvordan kan vi gøre det, hvis det hele er gemt i én række?
- Hvad hvis kun én kunde abonnerer på en tjeneste, og vi sletter denne registrering? Hvis vi sletter denne kundes registrering, sletter vi så også alle oplysninger om den service? (Dette kaldes en slet-anomali .) Betyder det, at vi ikke tilbyder den service længere? Hvis vi stadig tilbyder det, har vi mistet alle parametre relateret til den service.
Det er klart, at der vil være komplikationer ved at opbevare dataene for enhver virksomhed. Vi har alle været på modtagersiden af datakvalitetsproblemer - f.eks. fået regninger for tjenester, vi ikke har bestilt, blevet opkrævet to gange for det samme, eller fået sendt en pakke til den forkerte adresse. Disse ting sker, og på et lille datasæt er det relativt nemt at rette dem. Men hvad sker der, når vi har tusindvis eller endda millioner af rækker? Vi vil snart dedikere næsten al vores tid til at rette disse problemer.
Ydeevneproblemer
Ydeevneproblemer ske, når datasæt bliver for store til, at et ark kan håndteres effektivt. Du vil opleve problemer med datakvalitet meget hurtigere end problemer med ydeevnen, men det betyder ikke, at problemer med ydeevnen er uvæsentlige. Au contraire; problemer med ydeevne kan være endnu farligere end problemer med datakvalitet.
Det er almindeligt at søge efter specifikke rækker, indsætte nye rækker, opdatere eller slette celleværdier i eksisterende rækker og slette hele rækker. Alle disse handlinger kræver meget filtrering, hvilket ikke er noget problem på et lille datasæt. Men når dine ark bliver rigtig store, kan selv en simpel operation tage minutter. At bruge halvdelen af din arbejdsdag på at vente på, at filteret gør sit arbejde, er næppe et klogt valg.
Der er også det relaterede problem med redundans - lagring af de samme data flere gange på disken (f.eks. gemmes kundedata igen og igen i flere rækker). Dette vil også have en indflydelse på ydeevnen.
På anstændig hardware vil ark med tusindvis af rækker være okay. Men når du kommer ind i titusindvis af rækker, kan præstationsproblemer rejse deres grimme hoveder. Det er overflødigt at sige, at ark med hundredtusindvis eller endda millioner af rækker vil have ekstremt dårlig ydeevne.
På den anden side er databaser her for at løse præstationsproblemer. Når alt er sat ordentligt op, vil arbejdet med millioner af rækker ikke udgøre nogen udfordringer.
Håndtering af historiske data og rapporter
Et mere vigtigt problem med ark er sporing af dataændringer over tid. Hvis du blot sletter data fra ark, mister du dem. Hvis du beslutter dig for at gemme et dagligt ark (for at fange alle ændringerne og bevare historiske data), vil du snart finde dig selv begravet under tonsvis af ark. Det er virkelig tidskrævende at oprette rapporter fra en sådan struktur, og kvaliteten af alle rapporter, der genereres fra den, ville være meget tvivlsom.
Oplever du sådanne problemer med dine data?
I dagens artikel har vi diskuteret nogle ulemper ved at bruge ark til at organisere masser af data. Har du nogensinde oplevet nogen af disse problemer? Er du klar til at tage din virksomhed til næste niveau? Hvis svaret er "ja", er du på det rigtige sted! I næste uge lærer vi, hvordan en database løser problemer med lagring af data i ark.