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?
Dit is het vervolg op mijn vorige artikel "Spreadsheets versus databases:is het tijd om over te stappen?" waar we de meest voorkomende nadelen hebben besproken van het gebruik van spreadsheets om veel gegevens te ordenen. In dit artikel zullen we ontdekken hoe een database deze problemen oplost.
Een database gebruiken om gegevens te ordenen
Mijn motto is "gebruik de juiste technologie voor uw behoeften". Als u uw bedrijf via bladen kunt runnen, geweldig! Als u een eenvoudige database nodig heeft, is MS Access geen slechte optie. Maar als deze producten niet voor u werken, heeft u waarschijnlijk een aangepaste database en een webtoepassing nodig. De database slaat uw gegevens op; de web-app zal een gebruiksvriendelijke manier zijn om te communiceren met de database en te communiceren met de gegevenslaag.
Ons fictieve servicebedrijf was niet erg ingewikkeld, dus we konden het aandrijven met een vrij eenvoudig datamodel. Als je naar de onderstaande afbeelding kijkt, zie je dat alles wat we nodig hebben is opgeslagen in slechts vijf tabellen:client_type , client , service , replacement , en has_service .
Een belangrijke regel bij het ontwerpen van databases is om gerelateerde real-world gegevens op één plek te bewaren . In dit geval behouden we al onze client gegevens in de klantentabel. Op deze manier voorkomen we dat dezelfde gegevens op meerdere locaties worden opgeslagen (het eerder genoemde slechte soort redundantie). Als we iets wijzigen met betrekking tot een klant, doen we dit slechts één keer, in deze tabel. Dit zal de gegevenskwaliteit aanzienlijk verbeteren en goed zijn voor de prestaties.
De volgende tabel die gegevens uit de echte wereld bevat, is de service tafel. Nogmaals, we kunnen hier alle details met betrekking tot onze diensten opslaan en we kunnen de gegevens vrij efficiënt wijzigen.
De client tafel en de service tabel zijn real-world entiteiten die zonder de ander zouden kunnen bestaan. Het maken van een database met niet-gerelateerde entiteiten heeft echter niet zoveel zin - het is alsof je klanten hebt zonder producten of diensten zonder kopers. Dus we zullen deze twee tabellen met elkaar in verband brengen met behulp van de has_service tafel. Om informatie op te slaan over welke klanten welke service hebben, gebruiken we externe sleutels die fungeren als verwijzingen naar die klant en service. Deze refererende sleutels verwijzen terug naar records in de service- en klanttabellen. We kunnen ook alle aanvullende informatie met betrekking tot elke klant-servicerelatie in deze tabel bewaren.
Het client_type table wordt gebruikt als een woordenboek waarin elk mogelijk type client wordt opgeslagen. Het is het beste om verschillende segmentaties in afzonderlijke woordenboektabellen te bewaren (als we bijvoorbeeld klanttypen en typen werknemersrollen hadden, zouden we ze in verschillende tabellen opslaan). We hebben echter maar één tabel nodig omdat dit een eenvoudig model is.
De laatste tabel in ons model is de replacement tafel. We gebruiken het om twee services met elkaar in verband te brengen:een service die we willen vervangen en de vervangende service. Dit geeft ons de flexibiliteit om klanten vervangingen voor bestaande diensten aan te bieden (zoals het overstappen van het ene mobiele belabonnement naar het andere).
Databasevoordelen
Databases zijn ingewikkelder om in te stellen dan spreadsheets, maar dit geeft ze in feite een aantal belangrijke voordelen op het gebied van gegevensintegriteit en beveiliging:
Sleutels en beperkingen
Databases hebben ingebouwde regels en controles die, indien correct gebruikt, de meeste problemen met de gegevenskwaliteit en -prestaties zullen voorkomen. Primaire sleutels (kolommen die elk record in een tabel op unieke wijze identificeren) en externe sleutels (kolommen die verwijzen naar een record in een andere tabel) zijn van cruciaal belang voor de gegevensveiligheid, maar het definiëren van alternatieve of UNIEKE sleutels (die gegevens bevatten die uniek zijn voor elk record in een tabel ) is ook erg handig.
In relationele databases relateren sleutels gegevens uit verschillende tabellen. De primaire sleutel van de tabel is altijd UNIEK, terwijl een externe sleutel verwijst naar de primaire sleutel uit een andere tabel. Die referentie relateert gegevens uit deze twee tabellen (bijvoorbeeld de externe sleutels in de has_service tabel klantgegevens relateren aan de diensten die ze hebben). Het waarschuwt ons ook als we op het punt staan een primaire sleutel te verwijderen waarnaar in een andere tabel wordt verwezen. Dit voorkomt dat we records verwijderen die nog nodig zijn (als referenties) in een andere tabel.
Beperkingen definiëren het soort gegevens dat in een veld kan worden ingevoerd. We kunnen specificeren dat de gegevens een waarde moeten hebben (NIET NULL), een formaat definiëren voor telefoonnummers, alleen letters mogen bevatten, enzovoort. Dit betekent dat we gegevensproblemen kunnen voorkomen doordat mensen de verkeerde soort gegevens in een veld invoeren.
Beveiliging en machtigingen
Een andere zeer belangrijke databasefunctie is het beheren van de toegang tot uw gegevens . Dit geeft u de mogelijkheid om niet alleen in te stellen wie toegang heeft tot uw database, maar ook om te bepalen wat ze kunnen zien of wijzigen. Dit is een groot onderdeel van gegevensbeveiliging. U kunt bijvoorbeeld een gebruikersrol definiëren waarmee een werknemer klantgegevens kan wijzigen, maar geen servicegegevens. Ook zou je regels kunnen stellen waarop medewerkers gegevens kunnen wijzigen of verwijderen. Het is een goede standaardpraktijk om ervoor te zorgen dat mensen alleen toegang hebben tot de gegevens die ze nodig hebben om hun werk te doen.
Natuurlijk zouden we kunnen proberen om deze functionaliteiten opnieuw te creëren in sheets (althans op de een of andere manier), maar dat zou zeker "het wiel opnieuw uitvinden" zijn.
Kunnen we niet gewoon een spreadsheet gebruiken?
Natuurlijk konden we dat. We zouden werkbladen kunnen maken die hetzelfde patroon volgen als in het gegevensmodel. Dat zou veel dataproblemen oplossen, maar...
Het datamodel repliceren in sheets is zeker geen ideale optie. We zouden alle voordelen verliezen die het databasesysteem ons biedt, alle regels en beperkingen die gegevens "gezond" houden, alle dingen die onbedoelde verwijderingen en andere fouten voorkomen. We zouden de optimalisatie mislopen en als de dataset groot genoeg was, zouden de prestaties een klap krijgen.
Zelfs als we dat hebben opgelost, hoe zit het met het delen van gegevens, b.v. meerdere gebruikers tegelijkertijd hetzelfde blad gebruiken? Welke problemen met gegevensintegriteit en prestatie zou dit veroorzaken? Dit zou het tegenovergestelde zijn van dingen simpel houden.
Dus als u denkt dat sheets uw zakelijke behoeften niet aankunnen, bent u waarschijnlijk al op weg naar een database. Als u vastzit met gegevens die zijn opgeslagen in werkbladen en u wilt naar een database gaan, moet u:
- Maak een databasemodel waarin uw gegevens optimaal worden opgeslagen.
- Bouw een applicatie met de database op de achtergrond.
- Wis uw gegevens, transformeer ze (indien nodig) en importeer ze in de database.
- Blijf alleen met de database werken.
Wat moet u kiezen:spreadsheet of database?
In het artikel van vandaag hebben we geleerd hoe een database problemen oplost met het gebruik van werkbladen om veel gegevens te ordenen. Mijn advies is ga altijd voor de eenvoudigste oplossing voor je probleem . Als spreadsheets het werk goed doen, gebruik ze dan. Maar als u een datagedreven bedrijf bent, moet u zo snel mogelijk een database gaan gebruiken. Hoe langer u wacht met het opschonen en migreren van uw gegevens, hoe pijnlijker het proces zal zijn.