Tabeller, rader och nycklar

Förteckningen är öppnad. QUERY rullar ut ett hologram ovanför skrivbordet: tusentals poster hänger i luften i ett jämnt rutnät, och mellan en del av dem löper tunna bärnstensfärgade trådar. Du sträcker dig efter en — den klingar som en sträng. Det här är ingen hög med filer. Det är en väv.

Tabeller, rader, kolumner

En relationsdatabas liknar en prydlig katalog: data är sorterade i tabeller, och inuti varje tabell finns kolumner (vilka egenskaper vi lagrar) och rader (de enskilda posterna).

Ta köpartabellen users: varje rad är en köpare från det gamla Jorden, och kolumnerna beskriver dennes id, full_name, email, country, city, signup_date.

För att inte blanda ihop människor med samma namn har varje rad en primärnyckel (primary key) — en unik identifierare, oftast kolumnen id. Genom den kan andra tabeller hänvisa till den här raden med hjälp av en främmande nyckel (foreign key). Till exempel har en order i orders ett user_id — så minns ordern sin köpare. Just de där bärnstensfärgade trådarna på hologrammet är dessa kopplingar via nycklar.

QUERY: Så länge nyckeln håller, håller tråden. Ett och ett halvt sekel har gått, och varje order minns fortfarande sin människa.

Kör frågan och se hur «Kotomarkets» köpare ser ut — poster som ingen har öppnat sedan det gamla Nätets dagar:

Tables, rows, columns

A relational database is like a tidy catalog: the data is sorted into tables, and inside each table there are columns (what properties we store) and rows (the individual records).

Take the buyers’ table users: each row is one buyer from old Earth, and the columns describe their id, full_name, email, country, city, signup_date.

So that people with the same name don’t get confused, every row has a primary key — a unique identifier, usually the id column. Through it, other tables can reference this row using a foreign key. For example, an order in orders has a user_id — that’s how an order remembers its buyer. Those amber threads on the hologram are exactly these key-based links.

QUERY: As long as the key holds, the thread holds. A century and a half on, every order still remembers its person.

Run the query and see what Kotomarket’s buyers look like — records no one has opened since the days of the old Net:

Naturlig eller surrogatnyckel

Var kommer primärnyckeln ifrån? Det finns två vägar. En naturlig nyckel är ett verkligt attribut som redan är unikt: en köpares email, en boks ISBN, en valutakod. En surrogatnyckel är en konstgjord identifierare utan betydelse i yttervärlden: ett automatnummer eller en UUID. I «Kotomarket» används surrogat-id överallt — och det är en lärobokslösning:

-- Surrogatnyckel: databasen delar själv ut nästa nummer (PostgreSQL)
CREATE TABLE users (
  id        BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email     TEXT NOT NULL UNIQUE,  -- натуральный кандидат живёт рядом как UNIQUE
  full_name TEXT NOT NULL
);

Varför så? Primärnyckelns viktigaste egenskap: den ska inte ändras. Främmande nycklar i andra tabeller pekar på PK:n, och att byta dess värde skulle dra med sig en uppdatering av alla trådar på en gång — i orders, i events, överallt. Och «eviga» naturliga attribut finns knappt: människor byter email och efternamn, telefonnummer flyttas om, även ISBN ges ut på nytt. Ett surrogat-id ändras aldrig — just därför att det inte betyder något.

Krav på vilken primärnyckel som helst: unik, inte NULL, stabil. Spara naturliga nycklar åt små, oföränderliga uppslagstabeller — till exempel valutakoden 'RUB' från ISO 4217. Och unikheten hos en naturlig kandidat som email fäster du med ett separat UNIQUE-villkor, som i exemplet ovan: kopplingarna håller, data förblir ärliga, och köparen är ändå inte förbjuden att byta email.