Tabelle, righe e chiavi

L'inventario è aperto. QUERY dispiega sopra la scrivania un ologramma: migliaia di record sospesi in aria formano una griglia regolare, e tra alcuni di essi corrono sottili fili ambrati. Allunghi la mano verso uno di quei fili: vibra come una corda. Questo non è un mucchio di file. È un tessuto.

Tabelle, righe, colonne

Un database relazionale somiglia a un catalogo ordinato: i dati sono disposti in tabelle, e dentro ogni tabella ci sono colonne (le proprietà che conserviamo) e righe (i singoli record).

Prendi la tabella dei clienti users: ogni riga è un cliente della vecchia Terra, e le colonne ne descrivono id, full_name, email, country, city, signup_date.

Per non confondere persone con lo stesso nome, ogni riga ha una chiave primaria (primary key): un identificatore univoco, di solito la colonna id. Tramite questa chiave, altre tabelle possono fare riferimento alla riga usando una chiave esterna (foreign key). Per esempio, un ordine in orders ha un user_id: così l'ordine ricorda il proprio cliente. Quei fili ambrati nell'ologramma sono proprio i collegamenti tramite chiavi.

QUERY: Finché la chiave regge, il filo regge. È passato un secolo e mezzo, eppure ogni ordine ricorda ancora la sua persona.

Esegui la query e guarda che aspetto hanno i clienti di Kotomarket: record che nessuno apriva dai tempi della vecchia Rete.

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:

Chiave naturale o surrogata

Da dove arriva una chiave primaria? Ci sono due strade. Una chiave naturale è un attributo reale che è già univoco: l'email del cliente, l'ISBN di un libro, un codice valuta. Una chiave surrogata è un identificatore artificiale senza significato nel mondo esterno: una numerazione automatica o un UUID. In Kotomarket si usano ovunque degli id surrogati, ed è una scelta da manuale:

-- Chiave surrogata: il database assegna da sé il numero successivo (PostgreSQL)
CREATE TABLE users (
  id        BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email     TEXT NOT NULL UNIQUE,  -- il candidato naturale vive accanto come UNIQUE
  full_name TEXT NOT NULL
);

Perché così? La proprietà fondamentale di una chiave primaria è questa: non deve cambiare. Sulla PK puntano le chiavi esterne di altre tabelle, e cambiarne il valore obbligherebbe ad aggiornare tutti i fili in una volta sola: in orders, in events, ovunque. Inoltre gli attributi naturali davvero «eterni» sono rarissimi: le persone cambiano email e cognome, i numeri di telefono vengono riassegnati, perfino gli ISBN possono essere ristampati. Un id surrogato non cambia mai, proprio perché non significa nulla.

I requisiti di qualsiasi chiave primaria: univoca, non NULL, stabile. Lascia le chiavi naturali alle piccole tabelle di riferimento immutabili, per esempio il codice valuta 'RUB' della ISO 4217. E l'unicità di un candidato naturale come email fissala con un vincolo UNIQUE separato, come nell'esempio qui sopra: i collegamenti restano stabili, i dati restano corretti, e al cliente non viene impedito di cambiare email.