Tablice, redci i ključevi

Popis je otvoren. QUERY iznad radnog stola razvija hologram: tisuće zapisa lebde u zraku u urednoj mreži, a između nekih se protežu tanke jantarne niti. Posegneš za jednom — zazvoni poput strune. Ovo nije hrpa datoteka. Ovo je tkanina.

Tablice, redci, stupci

Relacijska baza nalik je urednom katalogu: podaci su razloženi po tablicama, a unutar svake tablice postoje stupci (koja svojstva čuvamo) i redci (konkretni zapisi).

Uzmi tablicu kupaca users: svaki je redak jedan kupac stare Zemlje, a stupci opisuju njegov id, full_name, email, country, city, signup_date.

Da se ljudi s istim imenima ne bi pomiješali, svaki redak ima primarni ključ (primary key) — jedinstveni identifikator, obično stupac id. Preko njega druge tablice mogu uputiti na taj redak pomoću vanjskog ključa (foreign key). Primjerice, u narudžbi orders postoji user_id — tako narudžba pamti svoga kupca. Upravo su one jantarne niti na hologramu veze po ključevima.

QUERY: Dok je ključ cijel — cijela je i nit. Prošlo je stoljeće i pol, a svaka narudžba još uvijek pamti svoga čovjeka.

Pokreni upit i pogledaj kako izgledaju kupci Kotomarketa — zapisi koje nitko nije otvarao od vremena stare Mreže:

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:

Prirodni ili surogatni ključ

Otkud dolazi primarni ključ? Putovi su dva. Prirodni ključ je stvarni atribut koji je ionako jedinstven: email kupca, ISBN knjige, kod valute. Surogatni ključ je umjetni identifikator bez značenja u vanjskome svijetu: automatska numeracija ili UUID. U Kotomarketu se posvuda koriste surogatni id — i to je tipično rješenje:

-- Surogatni ključ: baza sama izdaje sljedeći broj (PostgreSQL)
CREATE TABLE users (
  id        BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email     TEXT NOT NULL UNIQUE,  -- prirodni kandidat živi uz njega kao UNIQUE
  full_name TEXT NOT NULL
);

Zašto tako? Glavno svojstvo primarnog ključa: on se ne smije mijenjati. Na PK upućuju vanjski ključevi drugih tablica, a promjena vrijednosti povukla bi za sobom ažuriranje svih niti odjednom — u orders, u events, posvuda. A „vječnih” prirodnih atributa gotovo da i nema: ljudi mijenjaju email i prezimena, telefoni se sele, čak se i ISBN ponovno izdaje. Surogatni id ne mijenja se nikada — upravo zato što ništa ne znači.

Zahtjevi za svaki primarni ključ: jedinstven, nije NULL, stabilan. Prirodne ključeve ostavi malim nepromjenjivim šifrarnicima — primjerice, kodu valute 'RUB' iz ISO 4217. A jedinstvenost prirodnog kandidata poput email učvrsti zasebnim ograničenjem UNIQUE, kao u primjeru gore: veze ostaju, podaci ostaju pošteni, a kupcu nije zabranjeno promijeniti adresu e-pošte.