Att underhålla en databas (del 1)

Att underhålla en databas (del 1)
juni 14, 2012 adam.lith@squeed.com

Om du utvecklar en applikation som använder sig av en SQL databas så är chansen stor, om inte oundviklig, att du måste underhålla databasschemat under utveckling såväl som både schema och data när applikationen väl är satt i produktion. Jag tänkte snabbt gå igenom de saker som jag personligen ser som mest fundamentala då det gäller databashantering ur en programmerares synvinkel.

Underhåll

Att kunna bygga och underhålla en databas, att kunna hantera SQL, bör vara ett verktyg som finns i varje utvecklares verktygslåda. Men att kunna använda ett verktyg och att kunna använda det på ett ansvarfullt sätt är två olika saker. Majoriteten av all utvecklare är ansvarsfulla nog att veta att de bör versionshantera sin kod. Men jag vill påstå att det är lika viktigt att du har din databas i ditt versionerings system. Och detta bör du ha från dag ett. Jag har hört många som säger att de väntar med det tills dess systemet sätts i produktion, men detta är bara att vara onödigt lat.

Representation

Det finns två stycken grundläggande sätt att representera sin databas i kod/script-form. Det mest grundläggande, men enligt min pesonliga åsikt dock ej att föredra, är en statisk representation av din databas. Detta kan t.ex. vara en upsättning av SQL CREATE och ALTER script som beskriver hur du sätter upp databasen från scratch. Det andra sättet, och det jag rekommenderar, är att använda sig av ”förändrings”-script som beskriver databasen genom steg-för-steg modifikationer.

Som exempel säg att vi har en databas med en tabell Employees som skapades genom:

CREATE TABLE Employees 
( 
    EmployeeId BIGINT IDENTITY(1,1) NOT NULL, 
    Firstname NVARCHAR(50) NOT NULL 
)

Vi vill nu lägga till efternamn som en kolumn. Om du har en statisk representation skulle du ändra i den redan existerande filen till:

CREATE TABLE Employees 
( 
    EmployeeId BIGINT IDENTITY(1,1) NOT NULL, 
    Firstname NVARCHAR(50) NOT NULL, 
    Lastname NVARCHAR(50) NOT NULL 
)

Men om du använder dig av förändringsskript så skulle du skapa en ny fil där det står:

ALTER TABLE Employees 
ADD COLUMN Lastname NVARCHAR(50) NOT NULL 

Personligen så tycker jag att den största fördelen med förändringsskript är när man skall uppdatera en eller flera produktionsdatabaser, med en enkla anledningen att det bara är att köra skripten.

Detta förutsätter dock såklart att man vet vilka skript som redan körts på respektive databas. Mitt rekommenderade sätt att hantera det är att arbeta med Migrations, vilket jag snart kommer blogga om i nästa del här på Squeedbloggen.

Dessa förändringsskript skall behandlas som vilken annan kod som hällst, vilket betyder att den skall kodgranskas och testas (föreslagsvis så kan man ha ett automatisk test som applicerar alla förändringsskripten i ordning, mot den databas som man kör integrationstester emot).

2 Kommentarer

  1. Martin Sjöblom 6 år sedan

    Visst, kanske inte rocket science men ändå sunt.
    Ta steget vidare och ha script som bygger upp databasen inkrementellt!
    (stulet från kompis från 1993)
    1) Skapa tabell
    2) lägg till fält 1
    3) lägg till fält 2
    osv…

    Detta gör att create och updatescriptet är samma och vilken version man utgår från är mindre viktigt…

Pingbacks

  1. […] Att underhålla en databas (del 2 – Entity Framework Migrations) Posted on 2012-08-22 by adam.lith@squeed.com Denna blogpost är en fortsättning på Att underhålla en databas (del 1). […]

Lämna ett svar

E-postadressen publiceras inte. Obligatoriska fält är märkta *

*

Denna webbplats använder Akismet för att förhindra skräppost. Läs mer om hur dina kommentarsuppgifter behandlas.