Vad är databaser?

Introduktion

Databaser är viktiga komponenter för många moderna applikationer och verktyg. Som användare kan du interagera med dussintals eller hundratals databaser varje dag när du besöker webbplatser, använder applikationer på din telefon eller köper varor i mataffären. Som utvecklare är databaser kärnkomponenten som används för att bevara data längre än din applikations livstid. Men vad exakt är databaser och varför är de så vanliga?

I den här artikeln går vi igenom:

• vad är databaser
• hur de används av människor och applikationer för att hålla reda på olika typer av data
• vilka funktioner databaser erbjuder
• vilka typer av garantier de ger
• hur de jämförs med andra metoder för datalagring

Slutligen kommer vi att diskutera hur applikationer förlitar sig på databaser för att lagra och hämta data för att möjliggöra komplex funktionalitet.

Vad är databaser?

Databaser är logiska strukturer som används för att organisera och lagra data för framtida bearbetning, hämtning eller utvärdering. När det gäller datorer hanteras dessa strukturer nästan alltid av en applikation som kallas ett databashanteringssystem eller DBMS . DBMS hanterar dedikerade filer på datorns disk och presenterar ett logiskt gränssnitt för användare och applikationer.

Databashanteringssystem är vanligtvis utformade för att organisera data enligt ett specifikt mönster. Dessa mönster kallas databastyper eller databasmodeller, är de logiska och strukturella grunderna som bestämmer hur enskilda databitar lagras och hanteras. Det finns många olika databastyper, alla med sina egna fördelar och begränsningar. Relationsmodellen , som organiserar data i tabeller, rader och kolumner med korsreferenser, anses ofta vara standardparadigmet.

DBMS kan göra databaser som de styr tillgängliga via en mängd olika sätt, inklusive kommandoradsklienter, API:er, programmeringsbibliotek och administrativa gränssnitt. Genom dessa kanaler kan data tas in i systemet, organiseras efter behov och returneras efter önskemål.

Datapersistens kontra tillfällig lagring

Databaser lagrar data antingen på disk eller i minnet.

Lagring på disk sägs i allmänhet vara beständig , vilket innebär att data sparas på ett tillförlitligt sätt för senare, även om databasapplikationen eller själva datorn startar om.

Däremot sägs lagring i minnet vara flyktig eller flyktig . Efemerisk lagring överlever inte program- eller systemavstängning. Fördelen med minnesdatabaser är att de vanligtvis är mycket snabba.

I praktiken kommer många miljöer att använda en blandning av båda dessa typer av system för att få fördelarna med varje typ. För system som accepterar nya skrivningar till det tillfälliga lagret, kan detta åstadkommas genom att periodiskt spara tillfällig data på disken. Andra system använder skrivskyddade kopior i minnet av beständiga data för att påskynda läsåtkomsten. Dessa system kan ladda om data från backuplagringen när som helst för att uppdatera sina data.

Interagera med databaser för att hantera dina data

Även om databassystemet tar hand om hur data lagras på disk eller i minnet, tillhandahåller det också ett gränssnitt för användare eller applikationer. Gränssnitten för databasen måste kunna representera de operationer som externa parter kan utföra och måste kunna representera alla de datatyper som systemet stöder.

Enligt Wikipedia tillåter databaser vanligtvis följande fyra typer av interaktioner:

• Datadefinition :Skapa, ändra och ta bort definitioner av datastrukturen. Dessa operationer ändrar egenskaperna som påverkar hur databasen accepterar och lagrar data. Detta är viktigare i vissa typer av databaser än i andra.
• Uppdatera :Infoga, ändra och ta bort data i databasen. Dessa operationer ändrar den faktiska data som hanteras.
• Hämtning :Ge åtkomst till lagrad data. Data kan hämtas som de är eller kan ofta filtreras eller omvandlas för att massera den till ett mer användbart format. Många databassystem förstår rika frågespråk för att uppnå detta.
• Administration :Andra uppgifter som användarhantering, säkerhet, prestandaövervakning etc. som är nödvändiga men inte direkt relaterade till själva data.

Låt oss gå igenom dessa lite mer i detalj nedan.

Datadefinitioner styr formen och strukturen på data i systemet

Att skapa och kontrollera strukturen som din data kommer att ta i databasen är en viktig del av databashantering. Detta kan hjälpa dig att kontrollera formen eller strukturen på dina data innan du matar in den i systemet. Det låter dig också ställa in begränsningar för att se till att dina data följer vissa parametrar.

I databaser som arbetar på mycket regelbundna data, som relationsdatabaser, är dessa definitioner ofta kända som databasens schema . Ett databasschema är en strikt beskrivning av hur data måste formateras för att accepteras av en viss databas. Detta omfattar de specifika fält som måste finnas i enskilda poster samt krav på värden som datatyp, fältlängd, minimum- eller maximivärden etc. Ett databasschema är ett av de viktigaste verktygen en databasägare har för att påverka och kontrollera data som kommer att lagras i systemet.

Databashanteringssystem som värdesätter flexibilitet framför regelbundenhet kallas ofta för schemalösa databaser . Även om detta verkar antyda att data som lagras i dessa databaser inte har någon struktur, är detta vanligtvis inte fallet. Istället bestäms databasens struktur av själva datan och applikationens kunskap om och relation till datan. Databasen följer vanligtvis fortfarande en struktur, men databashanteringssystemet är mindre involverat i att upprätthålla begränsningar. Detta är ett designval som har fördelar och nackdelar beroende på situationen.

Datauppdateringar för att mata in, ändra och ta bort data från systemet

Datauppdateringar inkluderar alla åtgärder som:

• Matar in ny data i systemet
• Ändrar befintliga poster
• Tar bort poster från databasen

Dessa funktioner är väsentliga för alla databaser och utgör i många fall majoriteten av de åtgärder som databassystemet bearbetar. Dessa typer av aktiviteter – operationer som orsakar ändringar av data i systemet – kallas gemensamt för write operationer.

Skrivåtgärder är viktiga för alla datakällor som kommer att förändras över tiden. Även att ta bort data, en destruktiv åtgärd, anses vara en skrivoperation eftersom den modifierar data i systemet.

Eftersom skrivoperationer kan ändra data är dessa åtgärder potentiellt farliga. De flesta databasadministratörer konfigurerar sina system för att begränsa skrivoperationer till vissa applikationsprocesser för att minimera risken för oavsiktlig eller skadlig datamangling. Till exempel kräver dataanalys, som använder befintlig data för att svara på frågor om en webbplatss prestanda eller besökarnas beteende, endast läsbehörighet. Å andra sidan måste den del av applikationen som registrerar en användares beställningar kunna skriva ny data till databasen.

Hämta data för att extrahera information eller svara på specifika frågor

Att lagra data är inte särskilt användbart om du inte har ett sätt att hämta det när du behöver det. Eftersom att returnera data inte påverkar någon av informationen som för närvarande lagras i databasen kallas dessa åtgärder för läs operationer. Läsoperationer är det primära sättet att samla in data som redan är lagrad i en databas.

Databashanteringssystem har nästan alltid ett enkelt sätt att komma åt data med en unik identifierare, ofta kallad en primärnyckel . Detta ger åtkomst till valfri post genom att tillhandahålla nyckeln.

Många system har också sofistikerade metoder för att fråga databasen för att returnera datamängder som matchar specifika kriterier eller returnera partiell information om poster. Denna typ av frågeflexibilitet hjälper databashanteringssystemet att fungera som en databehandlare utöver dess grundläggande datalagringsmöjligheter. Genom att utveckla specifika frågor kan användare uppmana databassystemet att endast returnera den information de behöver. Den här funktionen används ofta i samband med skrivoperationer för att lokalisera och ändra en specifik post efter dess egenskaper.

Administrera databassystemet för att allt ska fungera smidigt

Den sista kategorin av åtgärder som databaser ofta stöder är administrativa funktioner. Detta är en bred, allmän klass av åtgärder som hjälper till att stödja databasmiljön utan att direkt påverka själva data. Några objekt som kan passa in i den här gruppen inkluderar:

• Hantera användare, behörigheter, autentisering och auktorisering
• Konfigurera och underhålla säkerhetskopior
• Konfigurera stödmediet för lagring
• Hantera replikering och andra skalningsöverväganden
• Tillhandahålla återställningsalternativ online och offline

Denna uppsättning åtgärder överensstämmer med de grundläggande administrativa frågorna som är vanliga för alla moderna applikationer.

Administrativ verksamhet kanske inte är central för grundläggande datahanteringsfunktioner, men dessa funktioner skiljer ofta liknande databashanteringssystem åt. Att enkelt kunna säkerhetskopiera och återställa data, implementera användarhantering som kopplas in i befintliga system eller skala din databas för att möta efterfrågan är alla viktiga funktioner för att arbeta i produktionen. Databaser som inte uppmärksammar dessa områden kämpar ofta för att få användning i verkliga miljöer.

Vilket ansvar har databaser?

Med tanke på ovanstående beskrivning, hur kan vi generalisera det primära ansvaret som databaser har? Svaret beror mycket på vilken typ av databas som används och dina applikationers krav. Trots det finns det en gemensam uppsättning ansvarsområden som alla databaser försöker tillhandahålla.

Säkra dataintegritet genom trogen registrering och rekonstituering

Dataintegritet är ett grundläggande krav för ett databassystem, oavsett dess syfte eller design. Data som laddas in i databasen bör kunna hämtas på ett tillförlitligt sätt utan oväntade ändringar, manipulationer eller radering. Detta kräver tillförlitliga metoder för att ladda och hämta data, samt serialisering och deserialisering av data efter behov för att lagra dem på fysiska medier.

Databaser förlitar sig ofta på funktioner för att verifiera data när de skrivs eller hämtas, som kontrollsummor, eller för att skydda mot problem som orsakas av oväntade avstängningar, med hjälp av tekniker som förutskrivningsloggar, till exempel. Dataintegritet blir mer utmanande ju mer distribuerat datalagret är, eftersom varje del av systemet måste återspegla det aktuella önskade tillståndet för varje dataobjekt. Detta uppnås ofta med mer robusta krav och svar från flera medlemmar närhelst data ändras i systemet.

Erbjuder prestanda som uppfyller kraven i distributionsmiljön

Databaser måste fungera tillräckligt för att vara användbara. De prestandaegenskaper du behöver beror mycket på de särskilda kraven i dina applikationer. Varje miljö har en unik balans mellan läs- och skrivförfrågningar och du måste bestämma dig för vad acceptabel prestanda betyder för båda dessa kategorier.

Databaser är generellt sett bättre på att utföra vissa typer av operationer än andra. Operativa prestandaegenskaper är ofta en återspegling av typen av databas som används, dataschemat eller strukturen och själva operationen. I vissa fall kan funktioner som indexering , som skapar en alternativ prestandaoptimerad lagring av vanliga data, kan ge snabbare hämtning för dessa objekt. Andra gånger kanske databasen helt enkelt inte passar de åtkomstmönster som efterfrågas. Detta är något att tänka på när du bestämmer dig för vilken typ av databas du behöver.

Ställa in processer för att möjliggöra säker samtidig åtkomst

Även om detta inte är ett strikt krav, praktiskt taget måste databaser tillåta samtidig åtkomst. Det betyder att flera parter måste kunna arbeta med databasen samtidigt. Posterna ska vara läsbara av valfritt antal användare samtidigt och skrivbara när de för närvarande inte är låsta av en annan användare.

Samtidig åtkomst innebär vanligtvis att databasen måste implementera några andra grundläggande funktioner som användarkonton, ett behörighetssystem och autentiserings- och auktoriseringsmekanismer. Den måste också utveckla strategier för att förhindra att flera användare försöker manipulera samma data samtidigt. Registerlåsning och transaktioner implementeras ofta för att lösa dessa problem.

Hämta data individuellt eller samlat

En av de grundläggande skyldigheterna för en databas är förmågan att hämta data på begäran. Förfrågningarna kan avse enskilda data som är associerade med en enskild post, eller så kan de involvera att hämta data som finns i många olika poster. Båda dessa fall måste vara möjliga i de flesta system.

I de flesta databaser tillhandahålls en viss nivå av databehandling av databasen själv under hämtning. Dessa kan inkludera följande typer av operationer:

• Söka efter kriterier
• Filtrering och efterlevnad av begränsningar
• Extraherar specifika fält
• Genomsnitt, sortering etc.

Dessa alternativ hjälper dig att formulera de data du vill ha och det format som skulle vara mest användbart.

Alternativ till databaser

Innan vi går vidare bör vi kort ta en titt på vilka alternativ du har om du inte använder en databas.

De flesta metoder som lagrar data kan klassificeras som en databas av något slag. Några få undantag inkluderar följande.

Lokalt minne eller temporära filsystem

Ibland producerar applikationer data som inte är användbar eller som bara är relevant för applikationens livslängd. I dessa fall kanske du vill behålla den datan i minnet eller ladda ner den till ett temporärt filsystem eftersom du inte behöver den när applikationen avslutas. I fall där data aldrig är användbar, kanske du vill inaktivera utdata helt eller logga den till /dev/null .

Serialisera programdata direkt till det lokala filsystemet

Ett annat exempel där en databas kanske inte krävs är där en liten mängd data kan serialiseras och deserialiseras direkt istället. Detta är endast praktiskt för små mängder data med ett förutsägbart användningsmönster som inte involverar mycket, om någon, samtidighet. Detta skalas inte bra men kan vara användbart i vissa fall, som att mata ut lokal logginformation.

Lagra filliknande objekt direkt på disk eller objektlagring

Ibland kan data från applikationer skrivas direkt till disken eller en alternativ butik istället för att lagras i en databas. Till exempel, om data redan är organiserade i ett filorienterat format, som en bild- eller ljudfil, och inte kräver ytterligare metadata, kan det vara enklast att lagra det direkt på disk eller till en dedikerad objektlagring.

Vad används databaser till?

Nästan alla applikationer och webbplatser som inte är helt statiska förlitar sig på en databas någonstans i sin miljö. Det primära syftet med databasen dikterar ofta vilken typ av databas som används, vilken data som lagras och vilka åtkomstmönster som används. Ofta används flera databassystem för att hantera olika typer av data med olika krav. Vissa databaser är tillräckligt flexibla för att fylla flera roller beroende på typen av olika datamängder.

Låt oss ta en titt på ett exempel för att diskutera kontaktpunkterna en typisk webbapplikation kan ha med databaser. Vi kommer att låtsas att applikationen innehåller ett grundläggande skyltfönster och säljer föremål som det spårar i ett lager.

Lagra och bearbeta webbplatsdata

En av de primära användningsområdena för databaser är att lagra och bearbeta data relaterade till webbplatsen. Dessa artiklar påverkar hur informationen på webbplatsen är organiserad och utgör i många fall det mesta av webbplatsens "innehåll".

I exempelapplikationen som nämns ovan skulle databasen fylla det mesta av innehållet för webbplatsen inklusive produktinformation, lagerinformation och användarprofilinformation. Detta innebär att databasen eller någon mellanliggande cache skulle konsulteras varje gång en produktlista, en produktdetaljsida eller en användarprofil behöver visas.

En databas skulle också vara involverad när man visar nuvarande och tidigare beställningar, beräknar fraktkostnad och tillämpar rabatter genom att kontrollera rabattkoder eller beräkna frekventa kundbelöningar. Vår exempelsajt skulle använda databassystemet för att korrekt bygga beställningar genom att kombinera produktinformation, lager och användarinformation. Den sammansatta informationen som registreras i en beställning skulle lagras i en databas igen för att spåra beställningshantering, tillåta returer, avbryta eller ändra beställningar eller möjliggöra bättre kundsupport.

Analysera information för att hjälpa till att fatta bättre beslut

Åtgärderna i den sista kategorin var relaterade till webbplatsens grundläggande funktionalitet. Även om dessa är mycket viktiga för att hantera datakraven för applikationslagret, representerar de inte hela bilden.

När din webbapplikation börjar registrera användare och behandla beställningar vill du förmodligen kunna svara på detaljerade frågor om hur olika produkter säljer, vilka dina mest lönsamma användare är och vilka faktorer som påverkar din försäljning. Det här är analytiska frågor som kan köras när som helst för att samla in uppdaterad information om din organisations trender och prestanda.

Dessa typer av operationer kallas ofta business intelligence eller analys . Tillsammans hjälper de organisationer att förstå vad som hände tidigare och att göra välgrundade förändringar. Databassystem lagrar det mesta av den data som används under dessa processer och måste tillhandahålla lämpliga verktyg eller frågemöjligheter för att svara på frågor om det.

I vår exempelapplikation kan databaserna tillfrågas för att svara på frågor om produkttrender, användarregistreringsnummer, vilka stater vi levererar till flest eller vilka våra mest lojala användare är. Dessa relativt grundläggande frågor kan användas för att komponera mer komplexa frågor för att bättre förstå och kontrollera faktorer som påverkar produktens prestanda.

Hantera programkonfiguration

Vissa typer av databaser används som lagringsplatser för konfigurationsvärden för annan programvara i nätverket. Dessa fungerar som en central sanningskälla för konfigurationsvärden på nätverket. När nya tjänster startas konfigureras de att kontrollera värdena för specifika nycklar på konfigurationsdatabasens nätverksadress. Detta gör att du kan lagra all information som behövs för att bootstrap-tjänster på en plats.

Efter bootstrapping kan applikationer konfigureras för att se om nycklarna relaterade till deras konfiguration ändras. Om en ändring upptäcks kan applikationen konfigurera om sig själv för att använda den nya konfigurationen. Denna process orkestreras ibland av en hanteringsprocess som rullar ut de nya värdena över tid genom att snurra ner gamla tjänster när de nya tjänsterna kommer upp, och ändra den aktiva konfigurationen över tid för att bibehålla tillgängligheten.

Vår applikation skulle kunna använda den här typen av databas för att lagra beständiga konfigurationsdata för hela vår applikationsmiljö. Våra applikationsservrar, webbservrar, lastbalanserare, meddelandeköer och mer kan konfigureras för att referera till en konfigurationsdatabas för att få deras produktionsinställningar. Applikationens utvecklare kan sedan ändra beteendet hos miljön genom att justera konfigurationsvärdena på en central plats.

Samla in loggar, händelser och andra utdata

Att köra applikationer som aktivt betjänar förfrågningar kan generera mycket utdata. Detta inkluderar loggfiler, händelser och annan utdata. Dessa kan skrivas till disk eller någon annan ohanterad plats, men detta begränsar deras användbarhet. Att samla in den här typen av data i en databas gör det lättare att arbeta med, upptäcka mönster och analysera händelser när något oväntat inträffar eller när du behöver ta reda på mer om historisk prestation.

Vår exempelapplikation kan samla in loggar från vart och ett av våra system i en databas för enklare analys. Detta kan hjälpa oss att hitta samband mellan händelser om vi försöker analysera källan till problem eller förstå hälsan hos vår miljö som helhet.

Separat kan vi samla in mätvärden som produceras av vår infrastruktur och kod i en tidsseriedatabas , en databas speciellt utformad för att spåra värden över tid. Denna databas kan användas för att driva realtidsövervaknings- och visualiseringsverktyg för att förse applikationens utvecklings- och driftteam med information om prestanda, felfrekvenser, etc.

Hur fungerar olika roller med databaser?

Databaser är grundläggande för många olika rollers arbete inom organisationer. I mindre team kan en eller ett fåtal personer ansvara för att utföra uppgifterna i olika roller. I större företag är dessa ansvarsområden ofta uppdelade i diskreta roller som utförs av dedikerade individer eller team.

Dataarkitekter

Dataarkitekter är ansvariga för den övergripande makrostrukturen för databassystemen, gränssnitten de exponerar för applikationer och utvecklingsteam, och den underliggande teknologin och infrastrukturen som krävs för att möta organisationens databehov.

Personer i denna roll bestämmer i allmänhet om lämplig databasmodell och implementering som kommer att användas för olika applikationer. De ansvarar för att implementera databasbeslut genom att undersöka alternativ, besluta om teknik, integrera den med befintliga system och utveckla en heltäckande datastrategi för organisationen. De hanterar datasystemen holistiskt och har ett finger med i att besluta om och implementera datamodeller för olika projekt.

DBA:er (databasadministratörer)

Databasadministratörer, eller DBA:er, är individer som ansvarar för att datasystemen fungerar smidigt. De ansvarar för att planera nya datasystem, installera och konfigurera mjukvara, sätta upp databassystem för andra parter och hantera prestanda. De är också ofta ansvariga för att säkra databasen, övervaka den för problem och göra justeringar av systemet för att optimera för användningsmönster.

Databasadministratörer är experter på både individuella databassystem och hur man integrerar dem väl med det underliggande operativsystemet och hårdvaran för att maximera prestanda. De arbetar mycket med team som använder databaserna för att hantera kapacitet och prestanda och för att hjälpa team att felsöka problem med databassystemet.

Apputvecklare

Applikationsutvecklare interagerar med databaser på många olika sätt. De utvecklar många av de applikationer som interagerar med databasen. Detta är mycket viktigt eftersom dessa nästan alltid är de enda applikationerna som styr hur enskilda användare eller kunder interagerar med data som hanteras av databassystemet. Prestanda, korrekthet och tillförlitlighet är oerhört viktigt för applikationsutvecklare.

Utvecklare hanterar de datastrukturer som är associerade med deras applikationer för att bevara deras data till disk. De måste skapa eller använda mekanismer som kan mappa deras programmeringsdata till databassystemet så att komponenterna kan arbeta tillsammans i harmoni. När applikationer förändras måste de hålla data och datastrukturer i databassystemet synkroniserade. Vi kommer att prata mer om hur utvecklare arbetar med databaser senare i artikeln.

SREs (site reliability engineers) och driftexperter

SREs (site reliability engineers) och driftspersonal interagerar med databassystem utifrån ett infrastruktur- och applikationskonfigurationsperspektiv. De kan vara ansvariga för att tillhandahålla ytterligare kapacitet, ställa upp databassystem, se till att databaskonfigurationen matchar organisationens riktlinjer, övervaka drifttid och hantera säkerhetskopieringar.

På många sätt har dessa individer överlappande ansvar med DBA:er, men är inte fokuserade enbart på databaser. Driftpersonal ser till att de system som applikationer som resten av organisationen förlitar sig på, inklusive databassystem, fungerar tillförlitligt och har minimal driftstopp.

Business intelligence och dataanalytiker

Business intelligence-avdelningar och dataanalytiker är i första hand intresserade av den data som redan är insamlad och tillgänglig i databassystemet. De arbetar med att utveckla insikter baserade på trender och mönster i data så att de kan förutsäga framtida resultat, ge organisationen råd om potentiella förändringar och svara på frågor om data för andra avdelningar som marknadsföring och försäljning.

Dataanalytiker kan i allmänhet arbeta uteslutande med skrivskyddad tillgång till datasystem. Frågorna de kör har ofta dramatiskt annorlunda prestandaegenskaper än de som används av de primära applikationerna. På grund av detta arbetar de ofta med databasreplikor, eller kopior, så att de kan utföra långvariga och prestandaintensiva samlade frågor som annars kan påverka resursanvändningen i det primära databassystemet.

Hur arbetar jag med databaser som utvecklare?

Så hur går man tillväga för att jobba med databaser som applikationsutvecklare? På en grundläggande nivå, om din applikation måste hantera och bevara tillstånd, kommer arbetet med en databas att vara en viktig del av din kod.

Översätta data mellan din applikation och databasen

Du måste skapa eller använda ett befintligt gränssnitt för att kommunicera med databasen. Du kan ansluta direkt till databasen med vanliga nätverksfunktioner, utnyttja enkla bibliotek eller programmeringsbibliotek på högre nivå (t.ex. frågebyggare eller ORM).

ORM , eller objektrelationsmappare, är mappningslager som översätter tabellerna som finns i relationsdatabasen till klasserna som används inom objektorienterade programspråk och vice versa. Även om den här översättningen ofta är användbar, är den aldrig perfekt. Obalans i objektrelationell impedans är en term som används för att beskriva friktionen som orsakas av skillnaden i hur relationsdatabaser och objektorienterade program strukturerar data.

Även om relationsdatabaser och objektorienterad programmering beskriver två specifika designval, är problemet med att översätta mellan applikationen och databasskiktet ett generaliserat sådant som existerar oavsett databastyp eller programmeringsparadigm. Databasabstraktionslager är en mer allmän term för programvara med ansvar för att översätta mellan dessa två sammanhang.

Hålla strukturella förändringar synkroniserade med databasen

Ett viktigt faktum som du kommer att upptäcka när du utvecklar dina applikationer är att eftersom databasen finns utanför din kodbas, behöver den särskild uppmärksamhet för att hantera ändringar i din datastruktur. Det här problemet är mer utbrett i vissa databasdesigner än andra.

Den vanligaste metoden för att synkronisera din applikations datastrukturer med din databas är en process som kallas databasmigrering eller schemamigrering (båda kända i dagligt tal helt enkelt som migration). Migrering innebär att du uppdaterar din databas struktur för att återspegla ändringar i takt med att din applikations datamodell utvecklas. Dessa tar vanligtvis formen av en serie filer, en för varje utveckling, som innehåller de påståenden som behövs för att omvandla databasen till det nya formatet.

Skydda åtkomst till dina data och rensa indata

Ett viktigt ansvar när du arbetar med databaser som utvecklare är att se till att dina applikationer inte tillåter obehörig åtkomst till data. Datasäkerhet är ett brett problem i flera lager med många intressenter. I slutändan kommer några av säkerhetsaspekterna att vara din plikt att ta hand om.

Din applikation kommer att kräva privilegierad åtkomst till din databas för att utföra rutinuppgifter. 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.