Skapa effektiva tabeller

Slutförd

Effektiv tabelldesign utgör grunden för alla databaser. Tabeller strukturerar dina data och avgör hur effektivt dina frågor får åtkomst till och ändrar information.

Utforma och skapa tabeller

Tabeller är de grundläggande byggstenarna i relationsdatabaser och organiserar data i rader och kolumner som representerar entiteter och deras attribut. I relationssystem definierar tabeller strukturen för lagring av transaktionsdata, framtvingar relationer via externa nycklar och utgör grunden för frågor och rapportering.

För flerdimensionell analys fungerar tabeller som faktatabeller som lagrar mätbara händelser och dimensionstabeller som ger kontext för analys. De designbeslut du fattar när du skapar tabeller – datatyper, kolumnstorlek, begränsningar och relationer – påverkar lagringseffektivitet, frågeprestanda, dataintegritet och skalbarhet direkt för både drifts- och analytiska arbetsbelastningar.

Välj lämpliga datatyper

Datatyper är grundläggande beslut som påverkar din databas. Fel val kan leda till bortkastad lagring, dålig prestanda, dataförlust eller programfel. Till skillnad från programkod som du enkelt kan omstrukturera kräver byte av kolumndatatyper i produktionsdatabaser ofta återskapade tabeller, vilket kan innebära timmar av stilleståndstid för stora tabeller.

Välj rätt datatyper när du utformar det ursprungliga schemat, eftersom det är den enklaste tiden att få det rätt. Tänk också noga på datatyper när:

• Du lagrar data där precision är viktigt
• Du arbetar med tabeller med stora volymer där lagringskostnaderna multipliceras
• Du definierar kolumner med vanliga frågor som fungerar snabbare med mindre typer

Utforska vanliga datatyper

Lämpliga datatyper påverkar lagring, prestanda och åtgärder:

Typkategori	Datatyper	Lagringsstorlek	Användningsriktlinjer	Example
Numeric	INT, BIGINT, , DECIMALFLOAT	4 byte, 8 byte, varierar	Välj baserat på intervall- och precisionsbehov	Quantity INT, , Revenue DECIMAL(10,2)Population BIGINT
String	VARCHAR, , CHARNVARCHAR	1 byte/tecken, fast, 2 bytes/tecken	Använd VARCHAR för data med variabel längd, CHAR för fast längd, NVARCHAR för Unicode	Email VARCHAR(100), , CountryCode CHAR(2)ProductName NVARCHAR(100)
Datum/tid	DATE, , DATETIME2DATETIMEOFFSET	3 byte, 6–8 byte, 10 byte	DATETIME2 ger bättre precision än DATETIME	BirthDate DATE, , OrderTimestamp DATETIME2EventTime DATETIMEOFFSET
Binär	VARBINARY, IMAGE	varies	För lagring av binära data som bilder eller dokument	ProfilePhoto VARBINARY(MAX), DocumentContent VARBINARY(MAX)
Särskilda	UNIQUEIDENTIFIER, , XMLJSON	16 bytes, varierar, ursprunglig binär	UNIQUEIDENTIFIER för GUID XML för XML-dokument JSON (SQL 2025+) för JSON-dokument i internt binärt format	RowGUID UNIQUEIDENTIFIER, , Config XMLSettings JSON

Datatypens nyanser kräver noggrann uppmärksamhet. Om du till exempel använder FLOAT för finansiella data i stället för DECIMAL kan det leda till avrundningsfel som inte kan åtgärdas utan att räkna om varje beroende värde. En UNIQUEIDENTIFIER primärnyckel när INT räcker tredubblar storleken på indexet och saktar ner varje JOIN operation. De flesta av dessa beslut påverkar databasens prestanda och kan avgöra om frågor körs på millisekunder eller minuter.

Beräkna storlekskrav för tabeller

Tabellstorlek handlar inte bara om lagringskostnader. det påverkar dina databasåtgärder direkt. Tabellstorleken påverkar säkerhetskopierings- och återställningstider, varaktigheter för återskapande av index och frågeprestanda.

Viktigt!

En dåligt utformad tabell som lagrar 200 byte per rad i stället för 100 byte fördubblar dina lagringsbehov, säkerhetskopieringstider och I/O-krav.

Ett annat scenario att planera för tabellstorlek är när du beräknar lagringskostnader för molndatabaser, designar för begränsat diskutrymme eller planerar arkivstrategier. Alla dessa scenarier kräver korrekta storleksuppskattningar för att fatta välgrundade beslut om resurser och åtgärder.

Ett detaljhandelsföretag som lagrar 100 miljoner transaktioner dagligen med ytterligare 50 byte per rad slösar till exempel 5 GB per dag – det är 1,8 TB årligen onödig lagring, plus proportionella ökningar av säkerhetskopieringstid och kostnader.

I följande exempel visas hur du beräknar tabellens Employee storlek:

-- 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/Råd

Du kan använda Copilot för att generera tabellens storleksuppskattning.

Utforma effektiva kolumner

I följande exempel visas en väl utformad Product tabell som tillämpar de principer som beskrivs i den här 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
);

Den här tabellen visar flera metodtips:

• Lämpliga datatyper: INT för primärnyckeln (mindre än BIGINT eller UNIQUEIDENTIFIER), DECIMAL(10,2) för exakta ekonomiska beräkningar i stället FLOATför , DATETIME2 för bättre precision än äldre DATETIME
• Kolumner med rätt storlek: NVARCHAR(100) för produktnamn och NVARCHAR(50) för kategorier baserat på förväntad datalängd
• Begränsningar: NOT NULL datakvalitet genom att förhindra saknade kritiska värden
• Standardvärden: Automatiska värden för StockQuantity (0) och LastRestocked (aktuell UTC-tid) minskar programkodens komplexitet
• Effektiv primärnyckel: IDENTITY genererar sekventiella nycklar som klustras effektivt och använder minimal lagring (4 byte jämfört med 16 byte för GUID)

Anmärkning

Det här exemplet använder NVARCHAR (2 byte per tecken) för Unicode-stöd. Om dina data endast består av ASCII-tecken, minskar VARCHAR (1 byte per tecken) stränglagringen till hälften. A ProductName VARCHAR(100) använder ~30 byte jämfört med ~60 byte för NVARCHAR(100) på ett 30-teckensnamn. På 10 miljoner rader sparar detta cirka 300 MB. Använd NVARCHAR för internationella data. Använd VARCHAR när lagringseffektiviteten är viktig och data förblir endast ASCII.

Utforma metodtips

Använd de här huvudprinciperna när du utformar och implementerar tabeller för att säkerställa prestanda och underhåll:

• Använda lämpliga datatyper – Mindre datatyper minskar lagringen och förbättrar prestanda
• Överväg tabellstorlek tidigt – Beräkna radstorlek och total tabellstorlek för att planera lagring och indexering
• Implementera meningsfulla begränsningar – Säkerställa datakvalitet på databasnivå
• Planera för tillväxt – Utforma tabeller för att hantera framtida datavolymer
• Index strategiskt – Indexkolumner som används i WHERE, JOIN och ORDER BY-klasuler
• Välj columnstore för analys – Använda columnstore-index för stora tabeller med analysfrågor
• Normalisera när det är lämpligt – Balansera normalisering med frågeprestandabehov
• Övervaka rad- och sidkomprimering – Aktivera komprimering för stora tabeller för att spara lagringsutrymme

De flesta problem med databasprestanda beror på dåliga designbeslut som fattades tidigt under utvecklingen. Överdimensionerade datatyper slösar lagringsutrymme och gör frågor långsammare. Saknade eller felaktiga indextyper skapar flaskhalsar som resursuppgraderingar inte kan lösa. Förhindra dessa problem genom att investera tid i korrekt objektdesign innan du skapar eller ändrar tabeller. De beslut du fattar under designen – att välja lämpliga datatyper, uppskatta tabellstorlekar och välja rätt indextyper – har mycket större effekt på långsiktig prestanda och kostnad än någon optimering som du kan tillämpa senare.