sql >> Database >  >> RDS >> Database

Spreadsheets versus databases:is het tijd om over te stappen? Deel 1

Spreadsheets - Excel, Google Spreadsheets of een andere naam - zijn echt coole en krachtige tools. Maar dat geldt ook voor databases. Wanneer moet je bij een spreadsheet blijven? Wanneer moet je overstappen naar een database?

U kunt spreadsheets en databases voor vergelijkbare doeleinden gebruiken. Aangezien zowel gegevens worden georganiseerd als rapportage wordt vergemakkelijkt, kan het soms moeilijk zijn om te bepalen welke het beste is om te gebruiken. Laten we het dus hebben over de voor- en nadelen van elke optie.

In het begin…

Als u net begint met ondernemen, is een spreadsheet (of een 'blad') bijna altijd uw eerste keuze. Startups hebben zelden het budget om een ​​op maat gemaakte database te ondersteunen. En bovendien, uw bedrijf is nieuw; je hebt geen idee of het klein zal blijven, zal uitgroeien tot een enorm bedrijf, of ergens in het midden zal zijn.

Een andere factor is dat de structuur en organisatie van uw bedrijf waarschijnlijk zullen veranderen naarmate het groeit. Dus echt, het bouwen van een database aan het begin is geen gebruikelijke optie. Dit is waar bladen meestal in springen.

De belangrijkste reden om bladen te gebruiken is dat ze beschikbaar zijn. U kunt met slechts een paar klikken Microsoft Excel, Google Spreadsheets of elk ander spreadsheetprogramma gaan gebruiken. U hoeft geen ingewikkelde structuur te plannen; u kunt eenvoudig uw gegevens invoeren, berekeningen en rapporten maken en de informatie delen met collega's. Spreadsheets bieden veel coole ingebouwde mogelijkheden en ze kunnen een klein bedrijf een hele tijd doorstaan.

Dus laten we zeggen dat je al je gegevens op bladen hebt staan. Waarom zou u overwegen een database te bouwen? Met andere woorden, waarom zou u uw leven ingewikkeld maken als alles werkt?

Op dit punt raad ik je aan jezelf af te vragen hoe goed alles werkt. Onthoud dat alles goed werkt totdat het niet meer werkt. In het geval van bladen geldt:hoe meer gegevens u heeft, hoe meer problemen u kunt tegenkomen. Hoe helpen databases u om deze problemen te voorkomen? En wanneer moet je overwegen over te stappen?

Spreadsheets gebruiken om gegevens te ordenen

Laten we aannemen dat we een bedrijf zijn begonnen dat telecommunicatie- en internetdiensten levert aan klanten. We moeten bijhouden welke klant momenteel geabonneerd is op welke service. Klanten kunnen meer dan één actieve service tegelijk hebben en de service kan aan het einde van een bepaalde periode verlopen of automatisch worden verlengd.

Laten we eens kijken naar een oplossing die bladen gebruikt.

We hebben gewoon een lijst gemaakt van alle gegevens die we hebben, d.w.z. er is een mix van gegevens op één plek. We hebben klantgegevens (kolommen A tot E), servicetypes (kolom F) en servicedetails (kolommen G, H en J).

Op het eerste gezicht ziet alles er redelijk goed uit. We kunnen alle gegevens bekijken zonder ingewikkelde handelingen uit te voeren. We kunnen de gegevens die we nodig hebben filteren en draaitabellen of grafieken maken voor rapportagedoeleinden. Tot nu toe, zo goed.

Maar als we lakens blijven gebruiken wanneer we meer klanten krijgen, kunnen we een punt bereiken waarop alles te groot wordt voor de lakens om te beheren. En dit brengt een nieuwe reeks problemen met zich mee.

Potentiële problemen met spreadsheets

Vergeleken met spreadsheets zijn databases ingewikkeld. Maar deze "complicaties" hebben een nuttig doel; ze voorkomen of minimaliseren in ieder geval de volgende problemen:

Gegevenskwaliteit

Gegevenskwaliteit en -consistentie is een enorm probleem voor grotere vellen. Hoewel we van plan zijn om gegevens correct op te slaan, problemen met de gegevenskwaliteit zijn heel gebruikelijk. Mensen maken fouten, of we moeten onverwachte informatie invoeren. Bedenk eens hoe de onderstaande scenario's een probleem kunnen vormen:

  1. We willen een nieuwe klant toevoegen zonder hun servicetype op te geven. Moeten we de klantgegevens toevoegen en de servicegegevens weglaten? Als we alleen klanten kunnen invoegen die servicegegevens hebben, is dat een anomalie invoegen .
  2. Wat als we servicegegevens toevoegen zodra deze beschikbaar zijn, nadat we het klantrecord hebben aangemaakt?
  3. Wat als een klant zich abonneert op meerdere services? Moeten we voor elke service een nieuw record maken, aangezien we maar één servicetype per record kunnen hebben?
  4. Wat als we meerdere records voor één klant hebben en we de informatie van die klant moeten bijwerken? Tenzij we de informatie in alle relevante rijen wijzigen, zijn onze gegevens inconsistent. We kunnen twee verschillende adressen hebben voor hetzelfde account; hoe kunnen we in dat geval weten welke gegevens correct zijn?
  5. Wat gebeurt er als we gegevens verwijderen? Als we de hele rij verwijderen, verliezen we alle gegevens van die klant. Dit is geen goed idee; het is beter om alleen hun servicegegevens te verwijderen en hun klantgegevens te behouden. Maar hoe kunnen we dat doen als alles bij elkaar op één rij staat?
  6. Wat als slechts één klant zich abonneert op een service en we dat record verwijderen? Als we het record van die klant verwijderen, verwijderen we dan ook alle records van die service? (Dit wordt een delete anomalie genoemd) .) Betekent dit dat we die service niet meer aanbieden? Als we het nog steeds aanbieden, zijn we alle parameters met betrekking tot die service kwijt.

Het is duidelijk dat er voor elk bedrijf complicaties zullen optreden bij het opslaan van de gegevens. We hebben allemaal te maken gehad met problemen met de gegevenskwaliteit - b.v. rekeningen hebben gekregen voor diensten die we niet hebben besteld, twee keer voor hetzelfde in rekening zijn gebracht of een pakket naar het verkeerde adres hebben gestuurd. Deze dingen gebeuren, en op een kleine dataset is het relatief eenvoudig om ze op te lossen. Maar wat gebeurt er als we duizenden of zelfs miljoenen rijen hebben? We zouden binnenkort bijna al onze tijd besteden aan het oplossen van deze problemen.

Prestatieproblemen

Prestatieproblemen gebeuren wanneer gegevenssets te groot worden om efficiënt door een blad te worden verwerkt. U zult veel eerder problemen met de gegevenskwaliteit ervaren dan prestatieproblemen, maar dat betekent niet dat prestatieproblemen onbelangrijk zijn. Au contraire; prestatieproblemen kunnen zelfs gevaarlijker zijn dan problemen met de gegevenskwaliteit.

Het is gebruikelijk om naar specifieke rijen te zoeken, nieuwe rijen in te voegen, celwaarden in bestaande rijen bij te werken of te verwijderen en hele rijen te verwijderen. Al deze acties vereisen veel filtering, wat geen probleem is op een kleine dataset. Maar als uw vellen echt groot worden, kan zelfs een simpele handeling minuten duren. De helft van uw werkdag wachten tot het filter zijn werk doet, is nauwelijks een verstandige keuze.

Er is ook het gerelateerde probleem van redundantie:dezelfde gegevens meerdere keren op de schijf opslaan (klantgegevens worden bijvoorbeeld steeds opnieuw in meerdere rijen opgeslagen). Dit zal ook een impact hebben op de prestaties.

Op degelijke hardware zijn vellen met duizenden rijen in orde. Maar wanneer u in tienduizenden rijen komt, kunnen prestatieproblemen de kop opsteken. Onnodig te zeggen dat vellen met honderdduizenden of zelfs miljoenen rijen extreem slechte prestaties zullen hebben.

Aan de andere kant zijn databases er om prestatieproblemen op te lossen. Als alles goed is ingesteld, is het werken met miljoenen rijen geen uitdaging.

Historische gegevens en rapporten beheren

Een ander belangrijk probleem met bladen is het bijhouden van gegevenswijzigingen in de loop van de tijd. Als u eenvoudig gegevens van bladen verwijdert, verliest u deze. Als u besluit een dagelijks blad op te slaan (om alle wijzigingen vast te leggen en historische gegevens te bewaren), zult u al snel bedolven worden onder tonnen bladen. Het maken van rapporten op basis van een dergelijke structuur is erg tijdrovend en de kwaliteit van de rapporten die daaruit worden gegenereerd, zou zeer twijfelachtig zijn.

Ervaar je dergelijke problemen met je gegevens?

In het artikel van vandaag hebben we enkele nadelen besproken van het gebruik van werkbladen om veel gegevens te ordenen. Heb je ooit een van die problemen ervaren? Ben jij klaar om je bedrijf naar een hoger niveau te tillen? Als het antwoord "ja" is, bent u op de juiste plek! Volgende week leren we hoe een database problemen oplost met het opslaan van gegevens in werkbladen.


  1. Haal de dag van een datum in PostgreSQL

  2. Voorwaardelijke JOIN-instructie SQL Server

  3. Hoe PostgreSQL op DigitalOcean te implementeren

  4. Wat te doen (of niet te doen) over de beste wachtstatistieken