Bruk spesialiserte tabelltyper

  • 12 minutter

SQL Server støtter spesialiserte tabelltyper designet for spesifikke scenarioer og arbeidsbelastninger utover standard diskbaserte tabeller. Disse tabelltypene, inkludert in-memory,temporal, ekstern,LEDGER og GRAPH, løser spesifikke ytelses-, compliance- eller arkitekturutfordringer som standardtabeller ikke kan løse effektivt.

Å forstå når og hvordan man bruker disse spesialiserte tabelltypene er avgjørende for å designe effektive databaseløsninger som oppfyller applikasjonens krav.

Bruk tabeller optimalisert i minnet

Tradisjonelle diskbaserte tabeller pådrar seg forsinkelse fra disk-I/O, selv med caching. For scenarioer som krever høy hastighet, som tusenvis av transaksjoner per sekund med millisekunds responstid, blir disklatens flaskehalsen. Minnetabeller eliminerer dette ved å holde data helt i RAM med låsfri, optimistisk samtidighet.

Forstå når du skal bruke minnetabeller

Tabeller optimalisert i minnet gir betydelige ytelsesfordeler for spesifikke arbeidsbelastninger:

  • Sesjonstilstandslagring – Webapplikasjoner med millioner av samtidige sesjoner
  • Sanntidsanalyse – Finansielle handelssystemer som krever mikrosekundlatens
  • Høyfrekvent OLTP - Ordrebehandlingssystemer håndterer 10 000+ transaksjoner per sekund
  • Caching-lag – Ofte aksessert referansedata (produktkataloger, konfigurasjoner)
  • Stagingtabeller – ETL-prosesser med intensive innsettings-/oppdateringsoperasjoner

For eksempel brukte et netthandelsnettsted minnetabeller for handlekurvdata, som håndterte 50 000 samtidige handlekurver med svartider på under millisekund, og reduserte betalingsforsinkelsen med 80%.

Vurder avveininger

Minnetabeller lagrer de faktiske tabelldataene i RAM for raskere tilgang, mens tradisjonelle tabeller lagrer data på disk. Datastørrelsen er imidlertid begrenset av tilgjengelig RAM, og disse tabellene støtter ikke store objekttyper som VARCHAR(MAX), NVARCHAR(MAX), eller VARBINARY(MAX).

Selv om tabelldataene ligger i minnet, skriver SQL Server fortsatt transaksjonslogger til disken for å sikre holdbarhet. Dette betyr at du ikke mister forpliktede transaksjoner hvis serveren starter på nytt—dataene hentes tilbake fra transaksjonsloggen tilbake i minnet.

Du kan lage en tabell optimalisert i minnet ved å bruke alternativet MEMORY_OPTIMIZED = ON . Her er et eksempel:

-- Create in-memory optimized table
CREATE TABLE dbo.OrderCache (
    OrderID INT PRIMARY KEY NONCLUSTERED,
    CustomerID INT,
    OrderDate DATETIME2,
    Amount DECIMAL(10,2),
    INDEX IX_CustomerID NONCLUSTERED (CustomerID)
) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);

Bruk temporale tabeller

Tidstabeller sporer automatisk hele historikken over dataendringer. Når du oppdaterer eller sletter en rad, lagrer SQL Server automatisk den forrige versjonen i en lenket historikktabell med tidsstempler som viser når den versjonen var gyldig. Dette skjer transparent – du endrer data ved bruk av vanlige INSERT, UPDATE, og DELETE setninger, og databasemotoren håndterer versjonering.

Den viktigste fordelen er å spørre data slik de eksisterte til enhver tid. Du kan spørre «hva var lønnen til denne ansatte 1. januar 2025?» eller «vis meg alle produktene som var på lager forrige kvartal» uten å vedlikeholde komplekse revisjonstabeller eller skrive tilpasset versjonslogikk.

Temporale tabeller dekker behov innen etterlevelse, feilsøking og analyse:

  • Etterlevelse og revisjon – Finansielle opptegnelser som krever fullstendig endringshistorikk
  • Feilsøking – Undersøkelse av kontosaldoer på tidspunktet for omstridte transaksjoner fant sted
  • Trendanalyse – Analyse av hvordan produktpriser endret seg over kvartaler
  • Datagjenoppretting – Tilbakeføring av utilsiktede oppdateringer uten å gjenopprette sikkerhetskopier
  • Sakte skiftende dimensjoner - Datavarehus Type 2 dimensjoner automatisert

Vanlige forretningsscenarier inkluderer applikasjoner som sporer lønnsendringer og forfremmelser, lagerstyring som analyserer lagertrender, helsetjenester som fører pasientjournalhistorikk for overholdelse, og forsikringsendringer i forsikringsdekning for tvisteløsning.

Vurder fordeler for det temporale bordet

Temporale tabeller krever ingen endringer i applikasjonskode og tilbyr transparent historikksporing. Punkt-i-tid-spørringer bruker enkel syntaks, og automatisk opprydding håndterer gamle historikkdata. Temporale tabeller dobler imidlertid omtrent lagringsbehovet.

Temporale tabeller opprettholder automatisk en komplett historikk over dataendringer for revisjon og punkt-i-tid-analyse.

Du kan lage en temporal tabell ved å bruke alternativet SYSTEM_VERSIONING = ON . Temporale tabeller krever to ekstra DATETIME2 kolonner for å spore gyldighetsperioden for hver radversjon og en PERIOD FOR SYSTEM_TIME klausul for å definere hvilke kolonner som følger disse tidsstemplene. Her er et eksempel:

-- Create temporal table with automatic history tracking
CREATE TABLE Employee (
    EmployeeID INT PRIMARY KEY,
    EmployeeName NVARCHAR(100),
    Department NVARCHAR(50),
    SysStartTime DATETIME2 GENERATED ALWAYS AS ROW START,
    SysEndTime DATETIME2 GENERATED ALWAYS AS ROW END,
    PERIOD FOR SYSTEM_TIME (SysStartTime, SysEndTime)
) WITH (SYSTEM_VERSIONING = ON);

-- Query historical data
SELECT * FROM Employee
FOR SYSTEM_TIME AS OF '2026-01-01' 
WHERE EmployeeID = 1;

Når du lager en temporær tabell, lager SQL Server automatisk en historikktabell for å lagre tidligere radversjoner og håndterer begge tabellene transparent.

Bruk eksterne tabeller

Moderne dataarkitekturer har ofte data spredt over datalakes, bloblagring og flere systemer. Tradisjonelt må du ETL (extract, transform, load) all data inn i databasen før du spør om den. Eksterne tabeller muliggjør datavirtualisering for å spørre data der de befinner seg uten å flytte dem, noe som sparer lagringskostnader og ETL-kompleksitet.

Forstå når du skal bruke eksterne tabeller

Eksterne tabeller utmerker seg til å spørre data på tvers av distribuerte lagringssystemer:

  • Data lake-integrasjon – Søk i Parquet/CSV-filer i Azure Data Lake Storage uten å importere
  • Datautforskning – Analyser rådata før du bestemmer hva som skal importeres
  • Kostnadsoptimalisering – Unngå å duplisere data som allerede er lagret andre steder
  • Fødererte spørringer – Koble databasetabeller med filer i eksterne systemer
  • Arkivlagring – Få tilgang til historiske data lagret i billigere blob-lagring

Vanlige scenarier inkluderer å spørre år med loggfiler i datalakes sammen med transaksjonsdata, kombinere levende databaseposter med arkiverte blob-lagringsdata, få tilgang til eldre data uten full migrering, og spørre millioner av IoT-sensor-JSON-filer uten import.

Vurder ytelsesbegrensninger

Eksterne tabeller gir enhetlig spørring på tvers av kilder, men har begrensninger:

  • Ingen databevegelse eller duplisering av lagring
  • Ofte tregere enn native tabeller på grunn av nettverksforsinkelse og filparsing
  • Skrivebeskyttet (kan ikke oppdatere/slette i de fleste scenarioer)
  • Begrenset indeksering og optimalisering

Du kan lage en ekstern tabell ved å bruke setningen CREATE EXTERNAL TABLE med en datakilde og filformat. Her er et eksempel:

-- Create external table pointing to data lake
CREATE EXTERNAL TABLE dbo.ExternalSalesData (
    OrderID INT,
    CustomerID INT,
    OrderAmount DECIMAL(10,2),
    OrderDate DATE
) WITH (
    LOCATION = '/raw/sales/',
    DATA_SOURCE = DataLakeSource,
    FILE_FORMAT = ParquetFormat
);

Bruk hovedboktabeller

I regulerte bransjer er det viktig å bevise at data ikke har blitt tuklet med. Tradisjonelle databaser kan få data endret av administratorer, tilbakevirkende endringer gjort, eller revideringslogger slettet. Hovedboktabeller bruker kryptografisk verifisering inspirert av blokkjedeteknologi for å lage manipulasjonssikre poster som kan verifiseres uavhengig, og gir kryptografisk bevis på dataintegritet.

Forstå når du skal bruke hovedboktabeller

Hovedboktabeller dekker krav til regulatorisk etterlevelse og rettsmedisinsk revisjon:

  • Finansielle transaksjoner – Bank, betalingsbehandling, kryptovalutabørser
  • Forsyningskjede – Sporing av produktets opprinnelse, oppbevaring og autentisitet
  • Juridiske dokumenter – Kontrakter, avtaler, juridiske innleveringer som krever uforanderlighet
  • Helsevesen – Reseptjournaler, pasientsamtykkeskjemaer
  • Regjering - Stemmeregistreringer, landregister, utstedelse av tillatelser

For eksempel kan en bank bruke hovedboktabeller for å lagre transaksjonsposter, slik at revisorer kan verifisere at ingen transaksjoner er endret etter bokføring. Et forsyningskjedeselskap kan spore produktets opprinnelse ved hjelp av hovedboktabeller, og gi kundene bevis på ekthet.

Velg mellom oppdaterbare og kun append-baserte hovedbøker

Hovedboktabeller finnes i to typer. Oppdaterbare hovedboktabeller tillater INSERT, UPDATE, og operasjoner DELETE samtidig som alle endringer spores kryptografisk. Systemet lagrer automatisk tidligere versjoner i en historikktabell, lik temporale tabeller, men med den ekstra fordelen av manipulasjonssikker verifikasjon. Append-only hovedbokstabeller tillater INSERT kun operasjoner, og skaper virkelig uforanderlige poster for scenarier som krever absolutt dataintegritet.

Du kan kombinere begge teknologiene ved å lage tabeller som både er oppdaterbare hovedboktabeller og temporale tabeller, og dermed oppnå kryptografisk verifisering sammen med tidspunktsspørringsmuligheter.

For eksempel bruker et legemiddelselskap kun append-tabeller for data fra kliniske studier, og gir uavhengige revisorer kryptografisk bevis på at testresultatene ikke ble endret etter innsending.

Du kan lage en hovedboktabell ved å bruke alternativet LEDGER = ON . Her er et eksempel:

-- Create ledger table
CREATE TABLE dbo.FinancialTransaction (
    TransactionID INT PRIMARY KEY IDENTITY,
    AccountNumber NVARCHAR(20),
    Amount DECIMAL(15,2),
    TransactionType NVARCHAR(20)
) WITH (LEDGER = ON);

-- Append-only ledger provides immutability
CREATE TABLE dbo.AuditLog (
    LogID INT PRIMARY KEY IDENTITY,
    EventDescription NVARCHAR(500),
    EventTimestamp DATETIME2
) WITH (LEDGER = ON, APPEND_ONLY = ON);

Når du lager en hovedboktabell, legger SQL Server automatisk til skjulte kolonner og lager støttende databaseobjekter for å spore den kryptografiske kjeden. Hver radmodifikasjon genererer en kryptografisk hash som lenker til tidligere operasjoner, og skaper en manipulasjonssikker revisjonsspor. Du kan verifisere dataintegriteten ved hjelp av innebygde systemvisninger som sys.database_ledger_transactions og prosedyrer som sp_verify_database_ledger for å validere at kryptokjeden forblir ubrutt.

Bruk graftabeller

Relasjonsdatabaser utmerker seg med strukturerte data, men sliter med svært sammenkoblede data som krever mange joins. Å finne «venner av venner» eller «produkter relatert gjennom 3 grader av kategorier» blir komplisert med tradisjonelle tabeller. SQL Graph-funksjoner modellerer noder (entiteter) og kanter (relasjoner) nativt, noe som gjør komplekse relasjonsspørringer enkle og effektive.

Graftabeller forenkler relasjonsmodellering, men krever læring av ny syntaks. De gir intuitiv modellering av tilkoblede data, enklere spørringer for relasjonstraversering, og bedre ytelse for flerhoppsforespørsler. Det fleksible skjemaet tilpasser seg utviklende relasjoner. Graftabeller har imidlertid en læringskurve for MATCH syntaks og fungerer best for lesetunge relasjonsspørsler.

En database kan inneholde flere node- og kanttabeller som samarbeider for å modellere grafdataene dine. Du definerer hvilke tabeller som representerer noder og hvilke som representerer kanter basert på dine dataforhold.

Bemerkning

Graftabeller er ikke optimale for alle scenarioer. Unngå dem for enkle foreldre-barn-relasjoner hvor fremmednøkler fungerer fint, primært transaksjonsdata uten komplekse relasjoner, eller svært strukturerte, stabile skjemaer.

Forstå graftabellstrukturen

SQL Graph bruker to typer tabeller for å modellere relasjoner. Nodetabeller lagrer enheter og inkluderer automatisk en skjult $node_id kolonne som entydig identifiserer hver node. Kanttabeller lagrer relasjoner mellom noder og inkluderer skjulte kolonner $edge_id, $from_id, og $to_id for å opprettholde forbindelser. Disse spesielle kolonnene gjør det mulig for syntaksen MATCH å navigere effektivt gjennom relasjoner.

Du kan lage graftabeller ved å bruke AS NODE og AS EDGE syntaks. Her er et eksempel:

-- Create graph tables
CREATE TABLE Person AS NODE;
CREATE TABLE Manages AS EDGE;
CREATE TABLE Knows AS EDGE;

-- Insert nodes
INSERT INTO Person VALUES (1, 'Alice'), (2, 'Bob'), (3, 'Charlie');

-- Insert edges (relationships)
INSERT INTO Manages VALUES (1, 2), (2, 3);

-- Query relationships
SELECT Person1.name, Person2.name 
FROM Person AS Person1, Manages, Person AS Person2
WHERE MATCH (Person1-(Manages)->Person2)
AND Person1.id = 1;

Når du lager node- og kanttabeller, håndterer SQL Server automatisk de skjulte systemkolonnene som muliggjør effektive graftraverseringsforespørsler.

Hver spesialisert tabelltype har kompromisser: minnetabeller trenger RAM, temporale tabeller dobler lagring, eksterne tabeller legger til nettverksforsinkelse, hovedboktabeller forhindrer sletting, og graftabeller krever ny syntaks. Vi anbefaler å velge riktig tabelltype under designet, da disse beslutningene er vanskelige å endre etter utrulling.