Databaser og API-er

Hva: Filbasert databasemotor uten egen serverprosess.

Hvorfor: Rask å komme i gang med for lokale verktøy og mindre applikasjoner.

Bør kunne: Vite når SQLite er tilstrekkelig og når man trenger en full databaseserver.

Hva: Robust relasjonsdatabase med rik funksjonalitet.

Hvorfor: Industristandard for produksjonsapplikasjoner som trenger samtidighet og skala.

Bør kunne: Designe skjema og skrive effektive spørringer i Postgres.

Hva: Databaser bygget på tabeller og relasjoner mellom dem.

Hvorfor: Fortsatt den mest brukte databasetypen for strukturert data.

Bør kunne: Modellere data i tabeller fremfor nøstede dokumenter der det passer.

Hva: Prosessen med å redusere dataduplisering i skjemadesign.

Hvorfor: Forhindrer inkonsistent data når samme informasjon endres flere steder.

Bør kunne: Normalisere til tredje normalform, og vite når å bevisst denormalisere.

Hva: Én-til-mange og mange-til-mange mellom tabeller.

Hvorfor: De fleste virkelige datamodeller henger sammen på tvers av tabeller.

Bør kunne: Modellere relasjoner med riktige fremmednøkler.

Hva: Kombinering av rader fra flere tabeller i én spørring.

Hvorfor: Nødvendig for å hente sammenhengende data effektivt.

Bør kunne: Skrive inner, left og aggregerte joins uten å google syntaksen hver gang.

Hva: Grupper av operasjoner som lykkes eller feiler samlet.

Hvorfor: Forhindrer at data havner i en inkonsistent tilstand ved feil.

Bør kunne: Bruke transaksjoner ved operasjoner som må være atomiske.

Hva: Datastrukturer som gjør oppslag raskere på bekostning av skrivehastighet.

Hvorfor: Uten riktige indekser blir spørringer trege ved vekst i datamengde.

Bør kunne: Identifisere og legge til indekser basert på faktiske spørringsmønstre.

Hva: Versjonskontrollerte, inkrementelle endringer i databaseskjema.

Hvorfor: Lar team og deg selv endre skjema trygt og sporbart over tid.

Bør kunne: Skrive migrasjoner som kan kjøres frem og reverseres.

Hva: Regelmessig, testet sikkerhetskopiering av databaser.

Hvorfor: Data uten testet backup er data du før eller siden mister.

Bør kunne: Automatisere backup og faktisk teste gjenoppretting.

Hva: Kontroll av data både i applikasjonen og på databasenivå.

Hvorfor: Constraints i databasen er siste forsvarslinje mot ugyldig data.

Bør kunne: Bruke NOT NULL, UNIQUE og CHECK-constraints bevisst.

Hva: Eksplisitt avtalte formater for forespørsler og responser.

Hvorfor: Gjør det trygt for frontend og backend å utvikle uavhengig av hverandre.

Bør kunne: Definere kontrakter før implementasjon starter.

Hva: Spesifikasjonsformat for å beskrive REST-API-er maskinlesbart.

Hvorfor: Muliggjør autogenerert dokumentasjon og klientkode.

Bør kunne: Holde en OpenAPI-spesifikasjon synkronisert med API-et.

Hva: Oppdeling av store resultatsett i sider.

Hvorfor: Forhindrer at store spørringer overbelaster klient og server.

Bør kunne: Implementere offset- eller cursor-basert paginering der det passer.

Hva: Innsnevring av resultater basert på query-parametere.

Hvorfor: Lar klienter hente akkurat den dataen de trenger.

Bør kunne: Designe filterparametere som er forutsigbare og dokumenterte.

Hva: Kontroll over rekkefølgen på returnerte data.

Hvorfor: Ofte nødvendig for å presentere data meningsfullt i UI.

Bør kunne: Støtte sortering på flere felter uten SQL-injeksjon-risiko.

Hva: Mellomlagring av data for å unngå unødvendige databasekall.

Hvorfor: Reduserer last og forbedrer responstid for ofte forespurte data.

Bør kunne: Vite hva som er trygt å cache, og hvor lenge.