PostgreSQL støtter array-kolonner — en enkelt kolonne kan holde flere verdier av samme type. Dette er en distinktiv Postgres-funksjonalitet som er nyttig for å lagre lister (tags, roller, poengsum) uten en separat tabell, med operatorer og funksjoner for spørring.
posts (
id SERIAL ,
title TEXT,
tags TEXT[]
);
posts (title, tags)
(, [, ]),
(, );
type[]-syntaksen deklarerer en arraykolonne. Du setter inn med ARRAY[...] eller '{...}' literal-syntaks.
-- ANY — does the array contain a value?
SELECT * FROM posts WHERE 'ruby' = ANY(tags);
-- @> containment — does the array contain ALL of these?
SELECT * FROM posts WHERE tags @> ARRAY['ruby', 'web'];
-- && overlap — do the arrays share ANY element?
SELECT * FROM posts WHERE tags && ARRAY['tech', 'news'];
-- access by index (1-based!) and length
SELECT tags[1], array_length(tags, 1) FROM posts;
-- unnest — expand an array into rows
SELECT id, unnest(tags) AS tag FROM posts; -- one row per tag
Operatorer som ANY (inneholder en verdi), @> (inneslutning) og && (overlapping), pluss funksjoner som unnest (utvid til rader) og array_agg (aggreger rader til et array), gjør arrays spørbare.
-- a GIN index makes array containment/membership queries fast
CREATE INDEX idx_posts_tags ON posts USING GIN (tags);
-- now WHERE tags @> ARRAY['ruby'] uses the index
✓ USE for: simple lists tightly coupled to the row (tags, roles, a few scores)
where you don't need to query/join the individual values much
✗ AVOID when: you need to query, join, or maintain the values relationally,
or the list is large/complex → a separate related table (normalized) is better
→ Arrays are convenient but can violate normalization; use them judiciously.
Arraykolonner er en distinktiv og nyttig PostgreSQL-funksjonalitet, og å forstå dem er verdifullt både for å utnytte Postgres sine evner og for å ta gode designbeslutninger.
Arrays lar deg lagre flere verdier i en enkelt kolonne (tags, roller, lister) uten en separat tabell — praktisk for enkle lister som er tett koblet til en rad.
Å forstå hvordan du definerer, setter inn, og spesielt spør arrays (operatorer som ANY for medlemskap, @> for inneslutning, && for overlapping, og funksjoner som unnest for å utvide arrays til rader) er nødvendig for å bruke dem effektivt, og å vite at GIN-indekser gjør arrayspørringer effektive er viktig for ytelse.
Like viktig er designvurderingen av når du skal bruke arrays versus en normalisert relatert tabell: arrays er praktiske for enkle lister du ikke trenger å spørre, gjøre join på, eller vedlikeholde relasjonelt, men de kan bryte normalisering og bli tungvindt når du trenger å spørre individuelle verdier, gjøre join på dem, eller administrere en kompleks/stor liste — i hvilket tilfelle en separat relatert tabell er det bedre, normaliserte valget.
Å forstå denne avvekningen (arrays for bekvemmelighet med enkle koblede lister, separate tabeller for relasjonelt administrert data) gjenspeiler god designvurdering.
Da arrays er en nyttig, distinktiv Postgres-funksjonalitet som kan forenkle visse design (unngå en joinstabell for enkle lister) men kan misbrukes (denormalisere data som burde være relasjonelt), er å forstå arraykolonner — hvordan du definerer, spør og indekserer dem, og avgjørende når de er passende versus når en normalisert tabell er bedre — verdifull, praktisk relevant kunnskap for å designe Postgres-skjemaer som bruker riktig tilnærming for hver type data med flere verdier.