Tabele, rânduri și chei

Inventarul e deschis. QUERY desfășoară pe birou o hologramă: mii de înregistrări plutesc în aer într-o rețea ordonată, iar între unele se întind fire subțiri, chihlimbarii. Atingi unul și sună ca o coardă. Nu e un morman de fișiere. E o țesătură.

Tabele, rânduri, coloane

O bază de date relațională seamănă cu un catalog bine îngrijit: datele sunt așezate în tabele, iar fiecare tabel are coloane (ce proprietăți păstrăm) și rânduri (înregistrările concrete).

Ia tabelul cumpărătorilor users: fiecare rând este un cumpărător al vechiului Pământ, iar coloanele descriu id, full_name, email, country, city, signup_date.

Ca să nu încurci oamenii cu nume identice, fiecare rând are o cheie primară (primary key) — un identificator unic, de obicei coloana id. Prin ea, alte tabele pot trimite la acest rând cu ajutorul unei chei externe (foreign key). De exemplu, în comanda orders există user_id — așa își ține minte comanda cumpărătorul. Firele chihlimbarii de pe hologramă sunt tocmai legăturile prin chei.

QUERY: Cât timp cheia e întreagă, și firul rămâne întreg. A trecut un secol și jumătate, iar fiecare comandă încă își ține minte omul.

Rulează interogarea și vezi cum arată cumpărătorii „Kotomarket” — înregistrări pe care nu le-a mai deschis nimeni din vremea vechii Rețele:

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:

Cheie naturală sau surogat

De unde vine cheia primară? Există două variante. Cheia naturală este un atribut real care este oricum unic: emailul cumpărătorului, ISBN-ul unei cărți, codul monedei. Cheia surogat este un identificator artificial, fără sens în lumea exterioară: o autonumerotare sau un UUID. În „Kotomarket” se folosesc peste tot id-uri surogat — și aceasta este o soluție tipică:

-- Cheie surogat: baza emite singură următorul număr (PostgreSQL)
CREATE TABLE users (
  id        BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email     TEXT NOT NULL UNIQUE,  -- candidatul natural trăiește alături ca UNIQUE
  full_name TEXT NOT NULL
);

De ce așa? Proprietatea esențială a cheii primare este că ea nu trebuie să se schimbe. Cheile externe din alte tabele trimit la PK, iar schimbarea valorii ar cere actualizarea tuturor firelor deodată — în orders, în events, peste tot. În plus, atribute naturale „veșnice” aproape că nu există: oamenii își schimbă emailul și numele, telefoanele se reatribuie, până și ISBN-urile se reeditează. Un id surogat nu se schimbă niciodată tocmai fiindcă nu înseamnă nimic.

Cerințele pentru orice cheie primară: să fie unică, să nu fie NULL, să fie stabilă. Păstrează cheile naturale pentru micile tabele de referință care nu se schimbă — de exemplu, codul monedei 'RUB' din standardul ISO 4217. Iar unicitatea unui candidat natural precum email fixeaz-o cu o restricție UNIQUE separată, ca în exemplul de mai sus: legăturile se păstrează, datele rămân corecte, iar cumpărătorului nu îi interzici să-și schimbe emailul.