Tabele, vrstice in ključi

Popis je odprt. QUERY nad delovno mizo razgrne hologram: tisoči zapisov obvisijo v zraku v enakomerni mreži, med nekaterimi pa se napenjajo tanke jantarne niti. Sežeš po eni — zazveni kot struna. To ni kup datotek. To je tkanina.

Tabele, vrstice, stolpci

Relacijska baza je podobna urejenemu katalogu: podatki so razporejeni po tabelah, znotraj vsake tabele pa so stolpci (katere lastnosti hranimo) in vrstice (konkretni zapisi).

Vzemi tabelo kupcev users: vsaka vrstica je en kupec stare Zemlje, stolpci pa opisujejo njegov id, full_name, email, country, city, signup_date.

Da ne bi zamenjeval ljudi z enakimi imeni, ima vsaka vrstica primarni ključ (primary key) — enolični identifikator, običajno stolpec id. Prek njega lahko druge tabele kažejo na to vrstico s pomočjo tujega ključa (foreign key). Na primer, v naročilu orders je user_id — tako se naročilo spomni svojega kupca. Prav tiste jantarne niti na hologramu so povezave prek ključev.

QUERY: Dokler je ključ cel, je cela nit. Minilo je poldrugo stoletje, vsako naročilo pa se še vedno spomni svojega človeka.

Zaženi poizvedbo in poglej, kako izgledajo kupci Kotomarketa — zapisi, ki jih ni nihče odprl od časov starega Omrežja:

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:

Naravni ali nadomestni ključ

Od kod izvira primarni ključ? Poti sta dve. Naravni ključ je resničen atribut, ki je itak enoličen: email kupca, ISBN knjige, koda valute. Nadomestni ključ je umeten identifikator brez pomena v zunanjem svetu: samodejno številčenje ali UUID. V Kotomarketu se povsod uporabljajo nadomestni id — in to je tipska rešitev:

-- Nadomestni ključ: baza sama izda naslednjo številko (PostgreSQL)
CREATE TABLE users (
  id        BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email     TEXT NOT NULL UNIQUE,  -- naravni kandidat živi ob njem kot UNIQUE
  full_name TEXT NOT NULL
);

Zakaj tako? Glavna lastnost primarnega ključa: ne sme se spreminjati. Na PK se sklicujejo tuji ključi drugih tabel, sprememba vrednosti pa bi za seboj potegnila posodobitev vseh niti naenkrat — v orders, v events, povsod. »Večnih« naravnih atributov pa skoraj ni: ljudje menjajo email in priimke, telefonske številke se preselijo, celo ISBN doživi ponatis. Nadomestni id se ne spremeni nikoli — prav zato, ker nič ne pomeni.

Zahteve za vsak primarni ključ: enoličen, ne NULL, stabilen. Naravne ključe prepusti majhnim nespremenljivim šifrantom — na primer kodi valute 'RUB' iz ISO 4217. Enoličnost naravnega kandidata, kot je email, pa zapni z ločeno omejitvijo UNIQUE, kot v zgornjem primeru: povezave se ohranijo, podatki ostanejo pošteni, in kupcu ni prepovedano zamenjati pošte.