Redigerer Kolonneorientert database (avsnitt)

=== Radorienterte systemer ===
En vanlig metode for å lagre en tabell er å serialisere hver rad med data, slik:

 001:10,Nilsen,Thomas,60000;
 002:12,Moen,Erik,80000;
 003:11,Jørgensen,Anna,94000;
 004:22,Moen,Marit,55000;

Etter hvert som data settes inn i tabellen tildeles en intern ID <code>rad_id</code> som brukes internt i systemet for å referere til data. I dette tilfellet har postene sekvensielle <code>rad_id</code> uavhengig av brukertildelt <code>ansatt_id</code> . I dette eksemplet bruker DBMS-en korte heltall for å lagre <code>rad_id</code>-er. I praksis brukes normalt større tall på 64 bit eller 128 bit.

Radorienterte systemer er designet for å effisient returnere data for en hel rad eller [[Record|oppføring]] i så få operasjoner som mulig. Dette samsvarer med det vanlige bruksmønsteret der systemet prøver å hente informasjon om et bestemt objekt, for eksempel kontaktinformasjonen for en bruker i et [[Rolodex]]-system eller produktinformasjon for et netthandelsystem. Ved å lagre oppføringens data i en enkelt blokk på disken sammen med relaterte oppføringer kan systemet raskt hente oppføringer ved et minimum av diskoperasjoner.

Radorienterte systemer er ikke effisiente til å utføre [[Operator|operasjoner]] på hele [[Mengde|mengder]] (''set-wide operations'') på hele tabeller, i motsetning til et lite antall spesifikke oppføringer. For eksempel: For å finne alle oppføringer i eksempeltabellen hvor lønnen er mellom 40 000 og 50 000 må databasehåndteringssystemet skanne fullstendig gjennom hele tabellen på jakt etter samsvarende oppføringer. Mens eksempeltabellen ovenfor sannsynligvis vil passe inn i en enkelt diskblokk vil det fort ikke være tilfellet for en tabell med bare noen få hundre rader, og dermed vil flere diskoperasjoner være nødvendig for å hente dataene og undersøke dem.

For å forbedre ytelsen til denne typen operasjoner (som er veldig vanlige, og generelt poenget med å bruke et databasehåndteringssystem) støtter de fleste DBMS-er bruk av [[Databaseindeks|databaseindekser]] som lagrer alle verdiene fra en mengde med kolonner sammen med <code>rad_id</code>-[[Peker (informatikk)|pekere]] tilbake til den originale tabellen. En indeks for lønnskolonnen vil omtrent se slik ut:

 55000:004; 
 60000:001;
 80000:002;
 94000:003;

Siden de bare lagrer enkeltdata (i stedet for hele rader) er indeksene generelt mye mindre enn hoved-tabelllagrene. Skanning av denne mindre mengden med data reduserer antallet diskoperasjoner. Hvis indeksen er mye brukt kan den redusere tiden for vanlige operasjoner dramatisk. Vedlikehold av indekser legger imidlertid til [[Indirekte kostnader (informatikk)|indirekte kostnader]] i systemet, særlig når nye data skrives til databasen. Oppføringer må ikke bare lagres i hovedtabellen, men eventuelle tilknyttede indekser må også oppdateres.

Hovedårsaken til at indekser dramatisk forbedrer ytelsen på store datamengder er at databaseindekser på én eller flere kolonner typisk er sortert etter verdi, hvilket gjør at spørreoperasjoner om rekkevidder (som eksempelet ovenfor: "Finn alle oppføringer med lønn mellom 40 000 og 50 000") veldig raskt kan løses basert på indeksen (lavere [[tidskompleksitet]]).

En rekke radorienterte databaser er designet for å passe i [[Hovedminne|RAM]], en [[hovedminnedatabase]]. Disse systemene er ikke avhengige av diskoperasjoner, og har lik tilgang til hele datamengden. Dette reduserer behovet for indekser ettersom det kreves samme mengde operasjoner for å fullskanne originaldataene som en komplett indeks for typiske [[Aggregering (datavarehus)|aggregeringsformål]]. Slike systemer kan derfor være enklere og mindre, men kan bare håndtere databaser som passer i minnet.