Hvad er databaser?

Introduktion

Databaser er væsentlige komponenter for mange moderne applikationer og værktøjer. Som bruger kan du interagere med snesevis eller hundredvis af databaser hver dag, når du besøger websteder, bruger applikationer på din telefon eller køber varer i købmanden. Som udvikler er databaser kernekomponenten, der bruges til at bevare data ud over din applikations levetid. Men hvad er databaser helt præcist, og hvorfor er de så almindelige?

I denne artikel gennemgår vi:

• hvad databaser er
• hvordan de bruges af mennesker og applikationer til at holde styr på forskellige slags data
• hvilke funktioner tilbyder databaser
• hvilke typer garantier de giver
• hvordan de er sammenlignet med andre metoder til datalagring

Til sidst vil vi diskutere, hvordan applikationer er afhængige af databaser til lagring og hentning af data for at muliggøre kompleks funktionalitet.

Hvad er databaser?

Databaser er logiske strukturer, der bruges til at organisere og gemme data til fremtidig behandling, hentning eller evaluering. I forbindelse med computere administreres disse strukturer næsten altid af en applikation kaldet et databasestyringssystem eller DBMS . DBMS administrerer dedikerede filer på computerens disk og præsenterer en logisk grænseflade for brugere og applikationer.

Databasestyringssystemer er typisk designet til at organisere data efter et specifikt mønster. Disse mønstre, kaldet databasetyper eller databasemodeller, er det logiske og strukturelle grundlag, der bestemmer, hvordan individuelle stykker data lagres og administreres. Der er mange forskellige databasetyper, hver med deres egne fordele og begrænsninger. Den relationelle model , som organiserer data i tabeller, rækker og kolonner med krydshenvisninger, anses ofte for at være standardparadigmet.

DBMS'er kan gøre databaser, de styrer, tilgængelige via en række forskellige måder, herunder kommandolinjeklienter, API'er, programmeringsbiblioteker og administrative grænseflader. Via disse kanaler kan data indlæses i systemet, organiseres efter behov og returneres som anmodet.

Datapersistens vs flygtig opbevaring

Databaser gemmer data enten på disk eller i hukommelsen.

På disklagring siges generelt at være vedvarende , hvilket betyder, at dataene er pålideligt gemt til senere, selvom databaseapplikationen eller selve computeren genstarter.

I modsætning hertil siges lager i hukommelsen at være flyktig eller flygtig . Ephemeral storage overlever ikke program- eller systemlukning. Fordelen ved in-memory databaser er, at de typisk er meget hurtige.

I praksis vil mange miljøer bruge en blanding af begge disse typer systemer for at opnå fordelene ved hver type. For systemer, der accepterer nye skrivninger til det flygtige lag, kan dette opnås ved periodisk at gemme flygtige data på disken. Andre systemer bruger skrivebeskyttede kopier i hukommelsen af ​​vedvarende data for at fremskynde læseadgangen. Disse systemer kan til enhver tid genindlæse dataene fra backing-lageret for at opdatere deres data.

Interaktion med databaser for at administrere dine data

Mens databasesystemet tager sig af, hvordan dataene lagres på disk eller i hukommelsen, giver det også en grænseflade til brugere eller applikationer. Grænsefladerne til databasen skal kunne repræsentere de operationer, som eksterne parter kan udføre, og skal kunne repræsentere alle de datatyper, som systemet understøtter.

Ifølge Wikipedia tillader databaser typisk følgende fire typer interaktioner:

• Datadefinition :Opret, rediger og fjern definitioner af datastrukturen. Disse handlinger ændrer de egenskaber, der påvirker, hvordan databasen accepterer og gemmer data. Dette er vigtigere i nogle typer databaser end andre.
• Opdater :Indsæt, rediger og slet data i databasen. Disse handlinger ændrer de faktiske data, der administreres.
• Hentning :Giver adgang til de lagrede data. Data kan hentes som de er eller kan ofte filtreres eller transformeres for at massere dem til et mere nyttigt format. Mange databasesystemer forstår rige forespørgselssprog for at opnå dette.
• Administration :Andre opgaver som brugeradministration, sikkerhed, præstationsovervågning osv., der er nødvendige, men ikke direkte relateret til selve dataene.

Lad os gennemgå disse lidt mere detaljeret nedenfor.

Datadefinitioner styrer formen og strukturen af ​​data i systemet

Oprettelse og styring af strukturen, som dine data vil tage i databasen, er en vigtig del af databasestyring. Dette kan hjælpe dig med at kontrollere formen eller strukturen af ​​dine data, før du indsætter dem i systemet. Det giver dig også mulighed for at opsætte begrænsninger for at sikre, at dine data overholder visse parametre.

I databaser, der opererer på meget regulære data, som relationelle databaser, er disse definitioner ofte kendt som databasens skema . Et databaseskema er en streng oversigt over, hvordan data skal formateres for at blive accepteret af en bestemt database. Dette dækker over de specifikke felter, der skal være til stede i individuelle poster samt krav til værdier som datatype, feltlængde, minimum- eller maksimumværdier osv. Et databaseskema er et af de vigtigste værktøjer en databaseejer har til at påvirke og kontrollere de data, der vil blive lagret i systemet.

Databasestyringssystemer, der værdsætter fleksibilitet frem for regelmæssighed, omtales ofte som skemaløse databaser . Selvom dette synes at antyde, at de data, der er gemt i disse databaser, ikke har nogen struktur, er dette normalt ikke tilfældet. I stedet er databasens struktur bestemt af selve dataen og applikationens viden om og relation til dataene. Databasen overholder normalt stadig en struktur, men databasestyringssystemet er mindre involveret i at håndhæve begrænsninger. Dette er et designvalg, der har fordele og ulemper afhængigt af situationen.

Dataopdateringer til indlæsning, ændring og fjernelse af data fra systemet

Dataopdateringer inkluderer enhver handling, der:

• Indsætter nye data i systemet
• Ændrer eksisterende poster
• Sletter indgange fra databasen

Disse egenskaber er essentielle for enhver database og udgør i mange tilfælde størstedelen af ​​de handlinger, som databasesystemet behandler. Disse typer aktiviteter - operationer, der forårsager ændringer i dataene i systemet - er samlet kendt som write operationer.

Skrivehandlinger er vigtige for enhver datakilde, der vil ændre sig over tid. Selv fjernelse af data, en destruktiv handling, betragtes som en skriveoperation, da den ændrer dataene i systemet.

Da skriveoperationer kan ændre data, er disse handlinger potentielt farlige. De fleste databaseadministratorer konfigurerer deres systemer til at begrænse skriveoperationer til bestemte applikationsprocesser for at minimere risikoen for utilsigtet eller ondsindet datamangling. For eksempel kræver dataanalyse, som bruger eksisterende data til at besvare spørgsmål om et websteds ydeevne eller besøgendes adfærd, kun læsetilladelse. På den anden side skal den del af applikationen, der registrerer en brugers ordrer, kunne skrive nye data til databasen.

Hentning af data for at udtrække information eller besvare specifikke spørgsmål

Lagring af data er ikke særlig nyttigt, medmindre du har en måde at hente dem, når du har brug for det. Da returnering af data ikke påvirker nogen af ​​de oplysninger, der i øjeblikket er gemt i databasen, kaldes disse handlinger læs operationer. Læseoperationer er den primære måde at indsamle data, der allerede er lagret i en database.

Databasestyringssystemer har næsten altid en ligetil måde at få adgang til data ved hjælp af en unik identifikator, ofte kaldet en primær nøgle . Dette giver adgang til en hvilken som helst post ved at angive nøglen.

Mange systemer har også sofistikerede metoder til at forespørge databasen for at returnere datasæt, der matcher specifikke kriterier eller returnere delvise oplysninger om posteringer. Denne form for forespørgselsfleksibilitet hjælper databasestyringssystemet med at fungere som en databehandler ud over dets grundlæggende datalagringsfunktioner. Ved at udvikle specifikke forespørgsler kan brugere bede databasesystemet om kun at returnere de oplysninger, de har brug for. Denne funktion bruges ofte i forbindelse med skriveoperationer for at lokalisere og ændre en specifik post ved dens egenskaber.

Administration af databasesystemet for at holde alt kørende

Den sidste kategori af handlinger, som databaser ofte understøtter, er administrative funktioner. Dette er en bred, generel klasse af handlinger, der hjælper med at understøtte databasemiljøet uden direkte at påvirke selve dataene. Nogle elementer, der kan passe ind i denne gruppe, omfatter:

• Administration af brugere, tilladelser, godkendelse og godkendelse
• Opsætning og vedligeholdelse af sikkerhedskopier
• Konfiguration af sikkerhedsmediet til opbevaring
• Administration af replikering og andre skaleringsovervejelser
• Tilbyder online- og offlinegendannelsesmuligheder

Dette sæt handlinger stemmer overens med de grundlæggende administrative bekymringer, der er fælles for enhver moderne applikation.

Administrative operationer er måske ikke centrale for kernedatastyringsfunktionalitet, men disse funktioner adskiller ofte lignende databasestyringssystemer. At være i stand til nemt at sikkerhedskopiere og gendanne data, implementere brugeradministration, der kobles ind i eksisterende systemer, eller skalere din database for at imødekomme efterspørgslen er alle væsentlige funktioner for at arbejde i produktionen. Databaser, der undlader at være opmærksomme på disse områder, kæmper ofte for at blive adopteret i virkelige miljøer.

Hvilket ansvar har databaser?

Givet ovenstående beskrivelse, hvordan kan vi generalisere det primære ansvar, som databaser har? Svaret afhænger meget af typen af ​​database, der bruges, og dine applikationers krav. Alligevel er der et fælles sæt af ansvarsområder, som alle databaser søger at levere.

Sikring af dataintegritet gennem trofast registrering og rekonstituering

Dataintegritet er et grundlæggende krav til et databasesystem, uanset dets formål eller design. Data indlæst i databasen bør kunne hentes pålideligt uden uventet ændring, manipulation eller sletning. Dette kræver pålidelige metoder til at indlæse og hente data, samt serialisering og deserialisering af dataene efter behov for at gemme dem på fysiske medier.

Databaser er ofte afhængige af funktioner til at verificere data, efterhånden som de skrives eller hentes, som checksumming, eller for at beskytte mod problemer forårsaget af uventede nedlukninger, ved at bruge teknikker som for eksempel fremskrivningslogfiler. Dataintegritet bliver mere udfordrende, jo mere distribueret datalageret er, da hver del af systemet skal afspejle den aktuelle ønskede tilstand for hvert dataelement. Dette opnås ofte med mere robuste krav og svar fra flere medlemmer, når data ændres i systemet.

Tilbyder ydeevne, der opfylder kravene i implementeringsmiljøet

Databaser skal fungere tilstrækkeligt for at være nyttige. De ydelsesegenskaber, du har brug for, afhænger i høj grad af de særlige krav til dine applikationer. Hvert miljø har en unik balance mellem læse- og skriveanmodninger, og du bliver nødt til at beslutte, hvad acceptabel ydeevne betyder for begge disse kategorier.

Databaser er generelt bedre til at udføre visse typer operationer end andre. Operationelle præstationskarakteristika er ofte en afspejling af den anvendte type database, dataskemaet eller strukturen og selve operationen. I nogle tilfælde funktioner som indeksering , som skaber et alternativt ydelsesoptimeret lager af almindeligt tilgåede data, kan give hurtigere hentning af disse elementer. Andre gange passer databasen måske bare ikke godt til de adgangsmønstre, der anmodes om. Dette er noget, du skal overveje, når du beslutter dig for, hvilken type database du har brug for.

Opsætning af processer for at tillade sikker samtidig adgang

Selvom dette ikke er et strengt krav, skal databaser praktisk talt tillade samtidig adgang. Det betyder, at flere parter skal kunne arbejde med databasen på samme tid. Optegnelser skal kunne læses af et vilkårligt antal brugere på samme tid og skrives, når de ikke i øjeblikket er låst af en anden bruger.

Samtidig adgang betyder normalt, at databasen skal implementere nogle andre grundlæggende funktioner som brugerkonti, et tilladelsessystem og godkendelses- og autorisationsmekanismer. Det skal også udvikle strategier til at forhindre flere brugere i at forsøge at manipulere de samme data samtidigt. Registerlåsning og transaktioner implementeres ofte for at imødegå disse bekymringer.

Hentning af data individuelt eller samlet

Et af de grundlæggende ansvar for en database er evnen til at hente data efter anmodning. Anmodningerne kan være for individuelle stykker data, der er knyttet til en enkelt post, eller de kan involvere at hente de data, der findes i mange forskellige poster. Begge disse tilfælde skal være mulige i de fleste systemer.

I de fleste databaser leveres en vis grad af databehandling af databasen selv under hentning. Disse kan omfatte følgende typer operationer:

• Søgning efter kriterier
• Filtrering og overholdelse af begrænsninger
• Udtrækning af specifikke felter
• Gennemsnit, sortering osv.

Disse muligheder hjælper dig med at formulere de data, du ønsker, og det format, der ville være mest nyttigt.

Alternativer til databaser

Før vi går videre, bør vi kort tage et kig på, hvad dine muligheder er, hvis du ikke bruger en database.

De fleste metoder, der lagrer data, kan klassificeres som en database af en eller anden art. Nogle få undtagelser omfatter følgende.

Lokal hukommelse eller midlertidige filsystemer

Nogle gange producerer applikationer data, der ikke er nyttige, eller som kun er relevante for applikationens levetid. I disse tilfælde ønsker du måske at beholde disse data i hukommelsen eller overføre dem til et midlertidigt filsystem, da du ikke får brug for dem, når først applikationen afsluttes. I tilfælde, hvor dataene aldrig er nyttige, kan du ønske at deaktivere output helt eller logge det til /dev/null .

Serialisering af applikationsdata direkte til det lokale filsystem

Et andet tilfælde, hvor en database muligvis ikke er påkrævet, er, hvor en lille mængde data kan serialiseres og deserialiseres direkte i stedet. Dette er kun praktisk for små mængder data med et forudsigeligt brugsmønster, der ikke involverer meget, hvis nogen, samtidighed. Dette skaleres ikke godt, men kan være nyttigt i visse tilfælde, som f.eks. at udlæse lokal loginformation.

Lagring af fillignende objekter direkte på disk eller objektlager

Nogle gange kan data fra applikationer skrives direkte til disk eller et alternativt lager i stedet for at lagre i en database. For eksempel, hvis dataene allerede er organiseret i et filorienteret format, som et billede eller en lydfil, og ikke kræver yderligere metadata, kan det være nemmest at gemme dem direkte på disken eller i et dedikeret objektlager.

Hvad bruges databaser til?

Næsten alle applikationer og websteder, der ikke er helt statiske, er afhængige af en database et sted i deres miljø. Det primære formål med databasen dikterer ofte den anvendte type database, de lagrede data og de anvendte adgangsmønstre. Ofte er flere databasesystemer implementeret til at håndtere forskellige typer data med forskellige krav. Nogle databaser er fleksible nok til at opfylde flere roller afhængigt af arten af ​​forskellige datasæt.

Lad os tage et kig på et eksempel for at diskutere de berøringspunkter, en typisk webapplikation kan have med databaser. Vi foregiver, at applikationen indeholder en grundlæggende butiksfacade og sælger varer, som den sporer i en beholdning.

Lagring og behandling af webstedsdata

En af de primære anvendelser for databaser er lagring og behandling af data relateret til webstedet. Disse elementer påvirker, hvordan information på webstedet er organiseret og udgør i mange tilfælde det meste af webstedets "indhold".

I eksempelapplikationen nævnt ovenfor vil databasen udfylde det meste af indholdet på webstedet, herunder produktoplysninger, lageroplysninger og brugerprofiloplysninger. Dette betyder, at databasen eller en mellemliggende cache vil blive konsulteret, hver gang en produktliste, en produktdetaljeside eller en brugerprofil skal vises.

En database vil også være involveret, når du viser nuværende og tidligere ordrer, beregner forsendelsesomkostninger og anvender rabatter ved at kontrollere rabatkoder eller beregne hyppige kundebelønninger. Vores eksempelwebsted ville bruge databasesystemet til at opbygge ordrer korrekt ved at kombinere produktinformation, lagerbeholdning og brugerinformation. De sammensatte oplysninger, der er registreret i en ordre, vil blive gemt i en database igen for at spore ordrebehandling, tillade returnering, annullere eller ændre ordrer eller muliggøre bedre kundesupport.

Analyse af oplysninger for at hjælpe med at træffe bedre beslutninger

Handlingerne i den sidste kategori var relateret til hjemmesidens grundlæggende funktionalitet. Selvom disse er meget vigtige for at håndtere datakravene for applikationslaget, repræsenterer de ikke hele billedet.

Når din webapplikation begynder at registrere brugere og behandle ordrer, vil du sandsynligvis gerne være i stand til at svare på detaljerede spørgsmål om, hvordan forskellige produkter sælger, hvem dine mest profitable brugere er, og hvilke faktorer der påvirker dit salg. Disse er analytiske spørgsmål, der kan køres til enhver tid for at indsamle opdaterede efterretninger om din organisations tendenser og ydeevne.

Disse typer operationer kaldes ofte business intelligence eller analyse . Sammen hjælper de organisationer med at forstå, hvad der skete i fortiden, og med at foretage informerede ændringer. Databasesystemer gemmer de fleste af de data, der bruges under disse processer, og skal give passende værktøj eller forespørgselsfunktioner til at besvare spørgsmål om det.

I vores eksempelapplikation kan databaserne forespørges for at besvare spørgsmål om produkttendenser, brugerregistreringsnumre, hvilke stater vi sender til flest, eller hvem vores mest loyale brugere er. Disse relativt basale forespørgsler kan bruges til at komponere mere komplekse spørgsmål for bedre at forstå og kontrollere faktorer, der påvirker produktets ydeevne.

Administration af softwarekonfiguration

Nogle typer databaser bruges som opbevaringssteder for konfigurationsværdier for anden software på netværket. Disse tjener som en central kilde til sandhed for konfigurationsværdier på netværket. Efterhånden som nye tjenester startes op, konfigureres de til at kontrollere værdierne for specifikke nøgler på konfigurationsdatabasens netværksadresse. Dette gør det muligt for dig at gemme alle de nødvendige oplysninger til bootstrap-tjenester på ét sted.

Efter bootstrapping kan applikationer konfigureres til at holde øje med tasterne relateret til deres konfiguration for ændringer. Hvis der registreres en ændring, kan applikationen omkonfigurere sig selv til at bruge den nye konfiguration. Denne proces er nogle gange orkestreret af en administrationsproces, der ruller de nye værdier ud over tid ved at dreje gamle tjenester ned, efterhånden som de nye tjenester kommer op, og ændre den aktive konfiguration over tid for at opretholde tilgængeligheden.

Vores applikation kunne bruge denne type database til at gemme vedvarende konfigurationsdata for hele vores applikationsmiljø. Vores applikationsservere, webservere, belastningsbalancere, beskedkøer og mere kunne konfigureres til at referere til en konfigurationsdatabase for at få deres produktionsindstillinger. Applikationens udviklere kunne derefter ændre miljøets adfærd ved at justere konfigurationsværdier på en central placering.

Samling af logfiler, begivenheder og andet output

At køre applikationer, der aktivt betjener anmodninger, kan generere en masse output. Dette inkluderer logfiler, hændelser og andet output. Disse kan skrives til disk eller en anden ikke-administreret placering, men dette begrænser deres anvendelighed. Indsamling af denne type data i en database gør det lettere at arbejde med, spotte mønstre og analysere begivenheder, når der sker noget uventet, eller når du har brug for at finde ud af mere om historisk præstation.

Vores eksempelapplikation kan samle logfiler fra hvert af vores systemer i én database for lettere analyse. Dette kan hjælpe os med at finde sammenhænge mellem begivenheder, hvis vi prøver at analysere kilden til problemer eller forstå sundheden for vores miljø som helhed.

Separat kan vi indsamle metrics produceret af vores infrastruktur og kode i en tidsseriedatabase , en database specielt designet til at spore værdier over tid. Denne database kan bruges til at drive realtidsovervågnings- og visualiseringsværktøjer for at give applikationens udviklings- og driftsteams information om ydeevne, fejlfrekvenser osv.

Hvordan fungerer forskellige roller med databaser?

Databaser er grundlæggende for arbejdet i mange forskellige roller i organisationer. I mindre teams kan en eller nogle få personer være ansvarlige for at udføre opgaver i forskellige roller. I større virksomheder er disse ansvarsområder ofte opdelt i diskrete roller, der udføres af dedikerede personer eller teams.

Dataarkitekter

Dataarkitekter er ansvarlige for den overordnede makrostruktur af databasesystemerne, de grænseflader, de eksponerer for applikationer og udviklingsteams, og de underliggende teknologier og infrastruktur, der kræves for at opfylde organisationens databehov.

Personer i denne rolle beslutter generelt en passende databasemodel og implementering, der vil blive brugt til forskellige applikationer. De er ansvarlige for at implementere databasebeslutninger ved at undersøge muligheder, tage stilling til teknologi, integrere den med eksisterende systemer og udvikle en omfattende datastrategi for organisationen. De beskæftiger sig holistisk med datasystemerne og har medvirken til at beslutte og implementere datamodeller til forskellige projekter.

DBA'er (databaseadministratorer)

Databaseadministratorer eller DBA'er er personer, der er ansvarlige for at holde datasystemer kørende. De er ansvarlige for planlægning af nye datasystemer, installation og konfiguration af software, opsætning af databasesystemer for andre parter og styring af ydeevne. De er også ofte ansvarlige for at sikre databasen, overvåge den for problemer og foretage justeringer af systemet for at optimere til brugsmønstre.

Databaseadministratorer er eksperter i både individuelle databasesystemer samt hvordan man integrerer dem godt med det underliggende operativsystem og hardware for at maksimere ydeevnen. De arbejder meget med teams, der bruger databaserne til at hjælpe med at administrere kapacitet og ydeevne og til at hjælpe teams med at fejlfinde problemer med databasesystemet.

Applikationsudviklere

Applikationsudviklere interagerer med databaser på mange forskellige måder. De udvikler mange af de applikationer, der interagerer med databasen. Dette er meget vigtigt, fordi disse næsten altid er de eneste applikationer, der styrer, hvordan individuelle brugere eller kunder interagerer med de data, der administreres af databasesystemet. Ydeevne, korrekthed og pålidelighed er utroligt vigtige for applikationsudviklere.

Udviklere administrerer de datastrukturer, der er forbundet med deres applikationer, for at bevare deres data på disken. De skal skabe eller bruge mekanismer, der kan kortlægge deres programmeringsdata til databasesystemet, så komponenterne kan arbejde sammen i harmoni. Efterhånden som applikationer ændrer sig, skal de holde data og datastrukturer i databasesystemet synkroniseret. Vi vil tale mere om, hvordan udviklere arbejder med databaser senere i artiklen.

SRE'er (site reliability engineers) og driftsprofessionelle

SRE'er (site reliability engineers) og driftsprofessionelle interagerer med databasesystemer fra et infrastruktur- og applikationskonfigurationsperspektiv. De kan være ansvarlige for at klargøre yderligere kapacitet, oprette databasesystemer, sikre databasekonfigurationen matcher organisatoriske retningslinjer, overvåge oppetid og administrere sikkerhedskopier.

På mange måder har disse personer overlappende ansvar med DBA'er, men er ikke udelukkende fokuseret på databaser. Driftspersonalet sikrer, at de systemer, som applikationer, som resten af ​​organisationen er afhængige af, inklusive databasesystemer, fungerer pålideligt og har minimal nedetid.

Business intelligence og dataanalytikere

Business intelligence-afdelinger og dataanalytikere er primært interesserede i de data, der allerede er indsamlet og tilgængelig i databasesystemet. De arbejder på at udvikle indsigt baseret på tendenser og mønstre i dataene, så de kan forudsige fremtidige resultater, rådgive organisationen om potentielle ændringer og besvare spørgsmål om dataene for andre afdelinger som f.eks. marketing og salg.

Dataanalytikere kan generelt udelukkende arbejde med skrivebeskyttet adgang til datasystemer. De forespørgsler, de kører, har ofte dramatisk anderledes ydeevneegenskaber end dem, der bruges af de primære applikationer. På grund af dette arbejder de ofte med databasereplikaer eller kopier, så de kan udføre langvarige og ydeevneintensive samlede forespørgsler, som ellers kunne påvirke ressourceforbruget af det primære databasesystem.

Hvordan arbejder jeg med databaser som udvikler?

Så hvordan arbejder man egentlig med databaser som applikationsudvikler? På et grundlæggende niveau, hvis din applikation skal administrere og bestå tilstand, vil arbejdet med en database være en vigtig del af din kode.

Oversættelse af data mellem din applikation og databasen

Du skal oprette eller bruge en eksisterende grænseflade til at kommunikere med databasen. Du kan oprette forbindelse direkte til databasen ved hjælp af almindelige netværksfunktioner, udnytte simple biblioteker eller programmeringsbiblioteker på højere niveau (f.eks. forespørgselsbyggere eller ORM'er).

ORM'er , eller objektrelationelle kortlæggere, er kortlægningslag, der oversætter tabellerne fundet i relationsdatabasen til de klasser, der bruges inden for objektorienterede programsprog og omvendt. Selvom denne oversættelse ofte er nyttig, er den aldrig perfekt. Objekt-relationel impedans uoverensstemmelse er et udtryk, der bruges til at beskrive friktionen forårsaget af forskellen i, hvordan relationelle databaser og objektorienterede programmer strukturerer data.

Selvom relationelle databaser og objektorienteret programmering beskriver to specifikke designvalg, er problemet med at oversætte mellem applikationen og databaselaget et generaliseret problem, der eksisterer uanset databasetype eller programmeringsparadigme. Databaseabstraktionslag er en mere generel betegnelse for software med ansvaret for at oversætte mellem disse to sammenhænge.

Sådan holdes strukturelle ændringer synkroniseret med databasen

En vigtig kendsgerning, du vil opdage, når du udvikler dine applikationer, er, at da databasen eksisterer uden for din kodebase, skal den have særlig opmærksomhed for at håndtere ændringer i din datastruktur. Dette problem er mere udbredt i nogle databasedesigns end andre.

Den mest almindelige tilgang til at synkronisere din applikations datastrukturer med din database er en proces kaldet databasemigrering eller skemamigrering (begge kendt i daglig tale blot som migration). Migrering involverer opdatering af din databases struktur for at afspejle ændringer, efterhånden som din applikations datamodel udvikler sig. Disse har normalt form af en række filer, en for hver udvikling, der indeholder de sætninger, der er nødvendige for at transformere databasen til det nye format.

Beskyttelse af adgang til dine data og rensende input

Et vigtigt ansvar, når du arbejder med databaser som udvikler, er at sikre, at dine applikationer ikke tillader uautoriseret adgang til data. Datasikkerhed er et bredt, flerlagsproblem med mange interessenter. I sidste ende vil nogle af sikkerhedshensynene være din pligt til at passe på.

Din applikation kræver privilegeret adgang til din database for at udføre rutineopgaver. For safety, the database's authorization framework can help restrict the type of operations your application can perform. However, you need to ensure that your application restricts those operations appropriately. For example, if your application manages user profile data, you have to prevent a user from manipulating that access to view or edit other users' information.

One specific challenge is sanitizing user input. Sanitizing input means taking special precautions when operating on any data provided by a user. There is a long history of malicious actors using normal user input mechanisms to trick applications into revealing sensitive data. Crafting your applications to protect against these scenarios is an important skill.

Conclusion

Databases are an indispensable component in modern application development. Storing and controlling the stateful information related to your application and its environment is an important responsibility that requires reliability, performance, and flexibility.

Fortunately, there are many different database options designed to fulfil the requirements of different types of applications. In our next article, we'll take an in-depth look at the different types of databases available and how they can be used to match different types of application requirements.