Wat zijn gegenereerde kolommen?

Question

Accepted Answer

Een **gegenereerde kolom** is een kolom waarvan de waarde **automatisch wordt berekend** op basis van andere kolommen, in plaats van rechtstreeks te worden ingevoegd. PostgreSQL ondersteunt **opgeslagen** gegenereerde kolommen (Postgres 12+) — de berekende waarde wordt bij het schrijven berekend en opgeslagen. Ze houden afgeleide gegevens automatisch consistent.

## Gegenereerde kolom definiëren

```sql
CREATE TABLE products (
  id SERIAL PRIMARY KEY,
  price NUMERIC,
  quantity INT,
  -- a STORED generated column — computed from price and quantity
  total NUMERIC GENERATED ALWAYS AS (price * quantity) STORED
);

INSERT INTO products (price, quantity) VALUES (10, 3);
SELECT total FROM products;          -- 30 — computed automatically (you didn't insert it)
```

De `GENERATED ALWAYS AS (expression) STORED` clausule zorgt ervoor dat `total` altijd gelijk is aan `price * quantity` — berekend bij insert/update en opgeslagen. Je kunt hier niet rechtstreeks in invoegen (en hoeft ook niet); het is altijd afgeleid.

## Veel voorkomende toepassingen

```sql
-- a full name from parts
full_name TEXT GENERATED ALWAYS AS (first_name || ' ' || last_name) STORED

-- a normalized/lowercased value for searching
email_lower TEXT GENERATED ALWAYS AS (lower(email)) STORED

-- area from dimensions
area NUMERIC GENERATED ALWAYS AS (width * height) STORED

-- extract a value from JSONB into a real column (then index it)
user_id INT GENERATED ALWAYS AS ((data->>'user_id')::int) STORED
```

Gegenereerde kolommen zijn ideaal voor afgeleide waarden die je vaak opvraagt — ze blijven automatisch consistent en kunnen worden **geïndexeerd** (omdat ze opgeslagen zijn).

## Gegenereerde kolommen versus berekenen in query's versus triggers

```text
Generated column → derived value computed automatically, stored, indexable, consistent
Computing in a query (price*qty in SELECT) → no storage, but recomputed every query,
                                              can't be indexed directly
Trigger → more flexible but more complex; generated columns are simpler for pure derivations
→ Use generated columns for simple, deterministic derived values you query/index often.
```

## Waarom het belangrijk is

Gegenereerde kolommen zijn een handige PostgreSQL-functie voor **automatisch onderhoud van afgeleide gegevens**, en het begrijpen ervan is waardevol voor het consistent houden van berekende waarden en het maken ervan opvraagbaar.

Het kernvoordeel is dat de waarde van een gegenereerde kolom altijd automatisch wordt berekend op basis van andere kolommen en synchroon wordt gehouden — dus afgeleide gegevens (totalen, volledige namen, genormaliseerde waarden, uitgepakte JSONB-velden) blijven **consistent bij constructie** zonder dat de applicatiecode of handmatige updates hoeven te onthouden om het opnieuw te berekenen (waardoor een klasse van bugs wordt voorkomen waarbij afgeleide gegevens uit synchronisatie raken).

Omdat opgeslagen gegenereerde kolommen de waarde fysiek opslaan, kunnen ze ook worden **geïndexeerd** — wat bijzonder waardevol is voor dingen als een kleine letter-e-mail voor case-insensitive zoeken, of het extraheren van een JSONB-veld in een echte, indexeerbare kolom (een krachtig patroon dat JSONB-flexibiliteit met relationeel indexeren combineert).

Begrijpen wanneer gegenereerde kolommen moeten worden gebruikt versus alternatieven — gegenereerde kolommen voor eenvoudige, deterministische afgeleide waarden die je vaak opvraagt of indexeert (consistent, indexeerbaar, eenvoudig), versus berekenen in query's (geen opslag maar bij elke query opnieuw berekend en niet rechtstreeks indexeerbaar) of triggers (flexibeler maar complexer) — weerspiegelt goed ontwerpoordeel.

Omdat het consistent onderhoud van afgeleide/berekende gegevens een veel voorkomende behoefte is, en omdat gegenereerde kolommen een automatische, consistente, indexeerbare manier bieden om dit te doen (schoner dan handmatig onderhoud of triggers voor eenvoudige afleidingen), is het begrijpen van gegenereerde kolommen waardevol, praktisch relevant PostgreSQL-kennis voor het ontwerpen van schema's waarbij berekende waarden automatisch correct worden gehouden en efficiënt opvraagbaar worden gemaakt — een handige moderne Postgres-functie voor schone, consistente gegevensmodellering.