Ytelse og spørringsoptimalisering i PostgreSQL · leksjon

Velge passende datatyper

Velg de mest effektive datatypene for kolonnene dine for å minimere lagringsbehovet og optimalisere spørringsbehandlingen.

Leksjon 2 av 411 trinn

Velge passende datatyper er en gratis leksjon i Ytelse og spørringsoptimalisering i PostgreSQL på CoddyKit. Dette er leksjon 2 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Ytelse og spørringsoptimalisering i PostgreSQL, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Ytelse og spørringsoptimalisering i PostgreSQL inneholder totalt 4 leksjoner.

Hvorfor datatyper er viktige

Å velge riktig datatype for kolonnene i PostgreSQL er et grunnleggende trinn i utformingen av en effektiv database.

Valget påvirker lagring, spørringsytelse og dataintegritet. Med riktig datatype lagres dataene effektivt og behandles raskt.

Velge heltallstyper

PostgreSQL tilbyr flere heltallstyper, og hver av dem har ulik lagringsstørrelse og verdiområde:

SMALLINT: 2 byte, område fra -32 768 til +32 767
INTEGER (eller INT): 4 byte, område fra -2 147 483 648 til +2 147 483 647
BIGINT: 8 byte, område fra -9 223 372 036 854 775 808 til +9 223 372 036 854 775 807

Velg alltid den minste heltallstypen som trygt kan lagre det forventede verdiområdet, for å minimere diskplassen og forbedre ytelsen.

Demonstrasjon av heltallstyper

La oss se hvordan ulike heltallstyper defineres. Legg merke til at vi velger den minste typen som passer til verdien.

CREATE TABLE product_counts (
  small_count SMALLINT,
  medium_count INTEGER,
  large_count BIGINT
);

INSERT INTO product_counts (small_count, medium_count, large_count)
VALUES (100, 50000, 1000000000);

SELECT * FROM product_counts;

Numerisk presisjon

Når du arbeider med desimaltall, særlig pengebeløp, er presisjon avgjørende:

NUMERIC(p, s): Lagrer eksakte tall. p er det totale antallet sifre (presisjon), mens s er antallet sifre etter desimaltegnet (skala). Dette er nødvendig for økonomiske data.
REAL (4 byte) og DOUBLE PRECISION (8 byte): Lagrer omtrentlige flyttall. De er raskere, men kan gi små avrundingsfeil, og egner seg derfor ikke for pengebeløp.

Bruk NUMERIC når nøyaktighet er avgjørende, og bruk REAL eller DOUBLE PRECISION for vitenskapelige eller mindre kritiske beregninger der tilnærming er akseptabelt.

Valg for tekstlagring

For lagring av tekststrenger tilbyr PostgreSQL:

VARCHAR(n): En streng med variabel lengde og en brukerdefinert maksimal lengde n. Hvis du prøver å sette inn en lengre streng, blir den avkortet, eller det oppstår en feil.
TEXT: En streng med variabel lengde uten en eksplisitt maksimal lengde. Dette er ofte det mest fleksible valget.
CHAR(n): En streng med fast lengde. Hvis strengen er kortere enn n, fylles den ut med mellomrom. Dette frarådes generelt på grunn av mulige ytelsesproblemer og sløsing med plass.

I de fleste moderne applikasjoner foretrekkes VARCHAR (uten lengde, slik at den fungerer som TEXT) eller ganske enkelt TEXT på grunn av fleksibiliteten og den effektive lagringen.

VARCHAR kontra TEXT

Her er et eksempel som viser VARCHAR med en lengdebegrensning og TEXT uten en slik begrensning. Begge lagrer data effektivt basert på den faktiske lengden.

CREATE TABLE messages (
  short_msg VARCHAR(50),
  long_msg TEXT
);

INSERT INTO messages (short_msg, long_msg)
VALUES ('Hello World', 'This is a much longer message that can span multiple lines and characters.');

SELECT short_msg, LENGTH(short_msg), long_msg, LENGTH(long_msg) FROM messages;

Håndtering av dato og klokkeslett

PostgreSQL tilbyr robuste dato- og klokkesletttyper:

DATE: Lagrer bare dato (år, måned, dag).
TIME: Lagrer bare klokkeslett (time, minutt, sekund, brøkdeler av sekunder).
TIMESTAMP: Lagrer dato og klokkeslett. Den lagrer IKKE informasjon om tidssone.
TIMESTAMPTZ (TIMESTAMP WITH TIME ZONE): Lagrer dato og klokkeslett og konverterer det til UTC ved lagring. Dette er den anbefalte typen for de fleste applikasjoner, slik at du unngår problemer med tidssoner.

Foretrekk alltid TIMESTAMPTZ for tidsstempler for hendelser, med mindre du har en svært spesifikk grunn til å la være.

Spesialtyper: Boolean og UUID

To andre nyttige datatyper:

BOOLEAN: Lagrer verdiene true/false. Den er svært effektiv og krever bare 1 byte lagringsplass. PostgreSQL godtar 'true', 'false', 't', 'f', '1', '0', 'yes' og 'no' som inndata.
UUID: Lagrer universelt unike identifikatorer. Dette er 128-biters verdier som er nyttige for å generere unike primærnøkler uten konflikter mellom databasesekvenser, særlig i distribuerte systemer.

UUID-verdier kan genereres av PostgreSQL ved hjelp av funksjoner som gen_random_uuid() fra utvidelsen pgcrypto.

Kostnader ved typekonvertering

PostgreSQL håndterer ofte implisitte typekonverteringer (for eksempel når en streng som '123' konverteres til et heltall), men dette medfører en ytelseskostnad.

Når du sammenligner eller kobler sammen kolonner med ulike datatyper, kan PostgreSQL måtte utføre en konvertering på én eller begge sider. Dette kan hindre bruk av indekser og gjøre spørringene tregere.

Prøv alltid å sammenligne og koble sammen kolonner som har identiske datatyper. Hvis konvertering er nødvendig, bør du bruke eksplisitt typekonvertering (for eksempel column::INTEGER) for å gjøre dette tydelig og noen ganger hjelpe spørringsplanleggeren.

Utfordring: Datatyper

Se for deg at du utformer en tabell for lagring av registreringsopplysninger om brukere. Én kolonne må lagre om en bruker har bekreftet e-postadressen sin, og en annen må lagre en unik, globalt identifiserbar bruker-ID som kan genereres hvor som helst.

Besvar den i den interaktive leksjonen

Sammendrag av datatyper

Vi har gått gjennom hvor viktig det er å velge riktige datatyper for ytelse, lagring og dataintegritet.

Velg den minste heltallstypen som passer til dataene.
Bruk NUMERIC for eksakte desimalverdier (for eksempel penger).
Foretrekk TIMESTAMPTZ for lagring av datoer og klokkeslett med tidssoneinformasjon.
BOOLEAN egner seg best for true/false-flagg, mens UUID egner seg for globalt unike identifikatorer.
Unngå unødvendige typekonverteringer for å opprettholde god spørringsytelse.

Et gjennomtenkt valg av datatyper er en grunnpilar i effektiv databasedesign.

Gratis å komme i gang

Lær deg SQL med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs: 22
Leksjoner: 88

Start læringen gratis Se hele kurset

Ofte stilte spørsmål

Er leksjonen «Velge passende datatyper» gratis?

Ja – du kan lese valgfritt 3 av leksjonene i læringsstien Ytelse og spørringsoptimalisering i PostgreSQL, inkludert «Velge passende datatyper», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i Ytelse og spørringsoptimalisering i PostgreSQL inneholder totalt 4 leksjoner.

Hva lærer jeg i «Velge passende datatyper»?

Velg de mest effektive datatypene for kolonnene dine for å minimere lagringsbehovet og optimalisere spørringsbehandlingen. Du øver på Ytelse og spørringsoptimalisering i PostgreSQL med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Ytelse og spørringsoptimalisering i PostgreSQL?

Ingen tidligere erfaring er nødvendig. Ytelse og spørringsoptimalisering i PostgreSQL på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 2 av 4.

Hvor lang tid tar leksjonen «Velge passende datatyper»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Ytelse og spørringsoptimalisering i PostgreSQL-leksjonen?

Ja. Alle Ytelse og spørringsoptimalisering i PostgreSQL-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

Avveiinger mellom normalisering og denormalisering
Velge passende datatyper
Partisjonere store tabeller
Utforming av primærnøkler og surrogatnøkler

← Tilbake til Ytelse og spørringsoptimalisering i PostgreSQL