Tabelid, read ja võtmed

Inventuur on avatud. QUERY avab töölaua kohale holograammi: tuhanded kirjed ripuvad õhus ühtlase võrguna ja mõnede vahel jooksevad õhukesed merevaigukollased niidid. Sirutad käe ühe poole — see heliseb nagu keel. See pole failihunnik. See on kangas.

Tabelid, read, veerud

Relatsiooniline andmebaas sarnaneb korraliku kataloogiga: andmed on jaotatud tabelitesse ja iga tabeli sees on veerud (milliseid omadusi me hoiame) ja read (konkreetsed kirjed).

Võta ostjate tabel users: iga rida on üks vana Maa ostja ja veerud kirjeldavad tema id, full_name, email, country, city, signup_date.

Et mitte segi ajada ühesuguste nimedega inimesi, on igal real primaarvõti (primary key) — unikaalne identifikaator, tavaliselt veerg id. Selle kaudu saavad teised tabelid sellele reale viidata välisvõtme (foreign key) abil. Näiteks tellimuses orders on user_id — nii mäletab tellimus oma ostjat. Needsamad merevaigukollased niidid holograammil ongi seosed võtmete kaudu.

QUERY: Kuni võti on terve, on niit terve. Poolteist sajandit on möödunud, ja iga tellimus mäletab ikka veel oma inimest.

Käivita päring ja vaata, millised näevad välja „Kotomarketi“ ostjad — kirjed, mida keegi pole avanud vana Võrgu aegadest:

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:

Naturaalne või surrogaatvõti

Kust tuleb primaarvõti? Teid on kaks. Naturaalne võti on reaalne atribuut, mis on niigi unikaalne: ostja email, raamatu ISBN, valuutakood. Surrogaatvõti on tehislik identifikaator, millel pole välismaailmas tähendust: automaatne nummerdus või UUID. „Kotomarketis“ kasutatakse kõikjal surrogaatseid id-sid — ja see on tüüplahendus:

-- Surrogaatvõti: andmebaas annab ise välja järgmise numbri (PostgreSQL)
CREATE TABLE users (
  id        BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email     TEXT NOT NULL UNIQUE,  -- натуральный кандидат живёт рядом как UNIQUE
  full_name TEXT NOT NULL
);

Miks nii? Primaarvõtme põhiomadus: see ei tohi muutuda. PK-le viitavad teiste tabelite välisvõtmed ja väärtuse muutmine tooks kaasa kõigi niitide korraga uuendamise — tabelis orders, tabelis events, kõikjal. „Igaveseid“ naturaalseid atribuute aga peaaegu polegi: inimesed muudavad emaili ja perekonnanime, telefonid kolivad, isegi ISBN-e antakse uuesti välja. Surrogaatne id ei muutu kunagi — just seepärast, et see ei tähenda midagi.

Nõuded igale primaarvõtmele: unikaalne, mitte NULL, stabiilne. Naturaalsed võtmed jäta väikestele muutumatutele teatmikele — näiteks valuutakoodile 'RUB' ISO 4217-st. Naturaalse kandidaadi nagu email unikaalsust aga fikseeri eraldi piiranguga UNIQUE, nagu ülaltoodud näites: seosed säilivad, andmed jäävad ausaks ja ostjal pole keelatud oma emaili muuta.