Bygg effektive tabeller

  • 8 minutter

Effektiv tabelldesign danner grunnlaget for enhver database. Tabeller strukturerer dataene dine og bestemmer hvor effektivt spørringene dine får tilgang til og endrer informasjon.

Design og lag tabeller

Tabeller er de grunnleggende byggesteinene i relasjonsdatabaser, og organiserer data i rader og kolonner som representerer enheter og deres attributter. I relasjonssystemer definerer tabeller strukturen for lagring av transaksjonsdata, håndhever relasjoner gjennom fremmednøkler, og gir grunnlaget for spørringer og rapportering.

For multidimensjonal analyse fungerer tabeller som faktatabeller som lagrer målbare hendelser og dimensjonstabeller som gir kontekst for analysen. Designbeslutningene du tar når du lager tabeller – datatyper, kolonnestørrelser, begrensninger og relasjoner – påvirker direkte lagringseffektivitet, spørringsytelse, dataintegritet og skalerbarhet på tvers av både operative og analytiske arbeidsbelastninger.

Velg aktuelle datatyper

Datatyper er grunnleggende beslutninger som påvirker databasen din. Feil valg kan føre til bortkastet lagring, dårlig ytelse, datatap eller applikasjonsfeil. I motsetning til applikasjonskode som du enkelt kan refaktorere, krever endring av kolonnedatatyper i produksjonsdatabaser ofte ombygging av tabeller, noe som kan bety timer med nedetid for store tabeller.

Velg riktige datatyper når du designer det første skjemaet, da dette er det enkleste tidspunktet å få det riktig. Vurder også datatyper nøye når:

  • Du lagrer data der presisjon betyr noe
  • Du jobber med tabeller med høyt volum hvor lagringskostnadene multipliserer
  • Du definerer ofte forespurte kolonner som presterer raskere med mindre typer

Utforsk vanlige datatyper

Passende datatyper påvirker lagring, ytelse og drift:

Typekategori Datatyper Lagringsstørrelse Retningslinjer for bruk Eksempel
Numerisk INT, , BIGINT, DECIMALFLOAT 4 bytes, 8 bytes, varierer Velg basert på rekkevidde og presisjonsbehov Quantity INT, , Revenue DECIMAL(10,2)Population BIGINT
Streng VARCHAR, , CHARNVARCHAR 1 byte/char, fast, 2 bytes/char Bruk VARCHAR for data med variabel lengde, CHAR for fast lengde, NVARCHAR for Unicode Email VARCHAR(100), , CountryCode CHAR(2)ProductName NVARCHAR(100)
dato/klokkeslett DATE, , DATETIME2DATETIMEOFFSET 3 bytes, 6-8 bytes, 10 bytes DATETIME2 gir bedre presisjon enn DATETIME BirthDate DATE, , OrderTimestamp DATETIME2EventTime DATETIMEOFFSET
Binær VARBINARY, IMAGE varierer For lagring av binære data som bilder eller dokumenter ProfilePhoto VARBINARY(MAX), DocumentContent VARBINARY(MAX)
Spesial UNIQUEIDENTIFIER, , XMLJSON 16 byte, varierer, native binærfil UNIQUEIDENTIFIER for GUID-er, XML for XML-dokumenter, JSON (SQL 2025+) for JSON-dokumenter i native binærformat RowGUID UNIQUEIDENTIFIER, , Config XMLSettings JSON

Datatypenyanser krever nøye oppmerksomhet. For eksempel kan bruk FLOAT for finansielle data i stedet for DECIMAL introdusere avrundingsfeil som ikke kan fikses uten å beregne alle avhengige verdier på nytt. En UNIQUEIDENTIFIER primærnøkkel, når INT den er tilstrekkelig, tredobler indeksstørrelsen din og bremser alle JOIN operasjoner. De fleste av disse beslutningene påvirker ytelsen til databasen og kan avgjøre om spørringer kjøres på millisekunder eller minutter.

Krav til estimert tabellstørrelse

Bordstørrelse handler ikke bare om lagringskostnader; Det påvirker direkte databaseoperasjonene dine. Tabellstørrelsen påvirker sikkerhetskopierings- og gjenopprettingstider, varighet på indeksgjenoppbygging og spørringsytelse.

Viktig!

En dårlig designet tabell som lagrer 200 byte per rad i stedet for 100 byte, dobler lagringsbehovene, sikkerhetskopieringstidene og I/O-kravene dine.

Et annet scenario å planlegge for tabellstørrelse er når du beregner lagringskostnader for skydatabaser, designer for begrenset diskplass eller planlegger arkivstrategier. Disse scenariene krever alle nøyaktige størrelsesestimater for å kunne ta informerte beslutninger om ressurser og drift.

For eksempel kaster et detaljhandelsselskap som lagrer 100 millioner transaksjoner daglig med 50 byte ekstra per rad, 5 GB per dag—det tilsvarer 1,8TB unødvendig lagring årlig, pluss proporsjonale økninger i sikkerhetskopieringstid og kostnader.

Følgende eksempel viser hvordan man estimerer størrelsen for tabellen Employee :

-- Estimate row size for a table
-- Fixed-length columns: sum of column sizes
-- Variable-length: estimate average size
-- Example row calculation:
CREATE TABLE Employee (
    EmployeeID INT,              -- 4 bytes
    FirstName NVARCHAR(50),      -- ~2-100 bytes (avg 40)
    LastName NVARCHAR(50),       -- ~2-100 bytes (avg 40)
    HireDate DATE,               -- 3 bytes
    Salary DECIMAL(10,2)         -- 5 bytes
);  
-- Estimated row size: 4 + 40 + 40 + 3 + 5 = ~92 bytes
-- Plus row overhead (~7 bytes) = ~99 bytes per row
-- 1 million rows ≈ 94 MB

Tips

Du kan bruke Copilot for å hjelpe deg med å generere tabellstørrelsesestimatet.

Designeffektive kolonner

Følgende eksempel demonstrerer en godt designet Product tabell som anvender prinsippene som dekkes i denne enheten:

CREATE TABLE Product (
    ProductID INT PRIMARY KEY IDENTITY(1,1),       -- Auto-incrementing surrogate key (4 bytes)
    ProductName NVARCHAR(100) NOT NULL,             -- Unicode support, appropriate length, enforced
    Category NVARCHAR(50) NOT NULL,                 -- Smaller than ProductName (categorization needs less space)
    Price DECIMAL(10,2) NOT NULL,                   -- Exact precision for financial data
    StockQuantity INT NOT NULL DEFAULT 0,           -- Integer sufficient for inventory, default prevents nulls
    LastRestocked DATETIME2 DEFAULT GETUTCDATE()    -- Modern date type with automatic timestamp
);

Denne tabellen viser flere beste praksiser:

  • Passende datatyper: INT for primærnøkkelen (mindre enn BIGINT eller UNIQUEIDENTIFIER), DECIMAL(10,2) for presise finansielle beregninger i stedet for FLOAT, DATETIME2 for bedre presisjon enn legacy DATETIME
  • Kolonner i riktig størrelse: NVARCHAR(100) for produktnavn og NVARCHAR(50) for kategorier basert på forventet datalengde
  • Begrensninger: NOT NULL sikrer datakvalitet ved å forhindre manglende kritiske verdier
  • Standardverdier: Automatiske verdier for StockQuantity (0) og LastRestocked (gjeldende UTC-tid) reduserer applikasjonskodens kompleksitet
  • Effektiv primærnøkkel: IDENTITY genererer sekvensielle nøkler som klynger effektivt og bruker minimal lagringsplass (4 byte mot 16 byte for GUID)

Bemerkning

Dette eksempelet bruker NVARCHAR (2 byte per tegn) for Unicode-støtte. Hvis dataene dine kun er ASCII-baserte VARCHAR (1 byte per tegn) halverer du strenglagringen. A ProductName VARCHAR(100) bruker ~30 byte mot ~60 byte for NVARCHAR(100) et 30-tegns navn. På 10 millioner rader sparer dette omtrent 300 MB. Bruk NVARCHAR for internasjonale data; bruk VARCHAR når lagringseffektivitet er viktig og data vil forbli kun ASCII.

Anbefalte fremgangsmåter for utforming

Bruk disse nøkkelprinsippene når du designer og implementerer tabeller for å sikre ytelse og vedlikeholdbarhet:

  • Bruk passende datatyper – Mindre datatyper reduserer lagringsplass og forbedrer ytelsen
  • Vurder tabellstørrelse tidlig – Anslå radstørrelse og total tabellstørrelse for å planlegge lagring og indeksering
  • Implementer meningsfulle begrensninger – Sikre datakvalitet på databasenivå
  • Planlegg for vekst – Design tabeller for å håndtere fremtidig datavolum
  • Indekser strategisk – Indekser kolonner brukt i WHERE, JOIN, og ORDER BY setninger
  • Velg columnstore for analyse – Bruk columnstore-indekser for store tabeller med analytiske spørringer
  • Normaliser når det er hensiktsmessig – Balanser normalisering med behov for spørringsytelse
  • Skjermrad- og sidekomprimering – Aktiver komprimering for store tabeller for å spare lagringsplass

De fleste databaseytelsesproblemer skyldes dårlige designbeslutninger tatt tidlig i utviklingen. Overdimensjonerte datatyper sløser med lagring og trege spørringer. Manglende eller feil indekstyper skaper flaskehalser som ressursoppgraderinger ikke kan løse. Forebygg disse problemene ved å investere tid i riktig objektdesign før du lager eller endrer tabeller. Beslutningene du tar under designet—velge passende datatyper, estimere tabellstørrelser, velge riktige indekstyper—har langt større effekt på langsiktig ytelse og kostnad enn noen optimalisering du kan bruke senere.