Taulut, rivit ja avaimet

Luettelo on auki. QUERY levittää työpöydän ylle hologrammin: tuhannet tietueet leijuvat ilmassa tasaisena ruudukkona, ja joidenkin välillä venyy ohuita meripihkanvärisiä säikeitä. Kurotat yhteen – se soi kuin kielisoittimen kieli. Tämä ei ole kasa tiedostoja. Tämä on kangas.

Taulut, rivit, sarakkeet

Relaatiotietokanta muistuttaa siistiä luetteloa: data on jaettu tauluihin, ja jokaisen taulun sisällä on sarakkeita (mitä ominaisuuksia säilytämme) ja rivejä (yksittäisiä tietueita).

Ota ostajien taulu users: jokainen rivi on yksi vanhan Maan ostaja, ja sarakkeet kuvaavat hänen tietonsa id, full_name, email, country, city, signup_date.

Jotta samannimisiä ihmisiä ei sekoiteta, jokaisella rivillä on primääriavain (primary key) – ainutkertainen tunniste, yleensä id-sarake. Sen kautta muut taulut voivat viitata tähän riviin vierasavaimella (foreign key). Esimerkiksi tilauksessa orders on user_id – niin tilaus muistaa ostajansa. Ne samat meripihkanväriset säikeet hologrammissa ovat juuri näitä avainpohjaisia yhteyksiä.

QUERY: Niin kauan kuin avain on ehjä, säie on ehjä. Puolitoista vuosisataa on kulunut, ja jokainen tilaus muistaa yhä oman ihmisensä.

Aja kysely ja katso, miltä Kotomarketin ostajat näyttävät – tietueet, joita kukaan ei ole avannut vanhan Verkon ajoista:

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:

Luonnollinen vai surrogaattiavain

Mistä primääriavain tulee? Teitä on kaksi. Luonnollinen avain on todellinen attribuutti, joka on jo valmiiksi ainutkertainen: ostajan email, kirjan ISBN, valuuttakoodi. Surrogaattiavain on keinotekoinen tunniste, jolla ei ole merkitystä ulkomaailmassa: automaattinumerointi tai UUID. Kotomarketissa käytetään kaikkialla surrogaatteja id – ja se on tyypillinen ratkaisu:

-- Surrogaattiavain: tietokanta antaa itse seuraavan numeron (PostgreSQL)
CREATE TABLE users (
  id        BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email     TEXT NOT NULL UNIQUE,  -- natiivi kandidaatti elää vierellä UNIQUE-kenttänä
  full_name TEXT NOT NULL
);

Miksi näin? Primääriavaimen tärkein ominaisuus: se ei saa muuttua. Muiden taulujen vierasavaimet viittaavat primääriavaimeen, ja arvon vaihtaminen vetäisi mukanaan kaikkien säikeiden päivityksen kerralla – taulussa orders, taulussa events, kaikkialla. ”Ikuisia” luonnollisia attribuutteja ei juuri ole: ihmiset vaihtavat sähköpostia ja sukunimiä, puhelinnumerot vaihtavat omistajaa, jopa ISBN otetaan uudelleen käyttöön. Surrogaatti id ei muutu koskaan – juuri siksi, ettei se merkitse mitään.

Vaatimukset mille tahansa primääriavaimelle: ainutkertainen, ei NULL, vakaa. Jätä luonnolliset avaimet pienille, muuttumattomille hakutauluille – esimerkiksi ISO 4217 -valuuttakoodille 'RUB'. Ja luonnollisen kandidaatin kuten email ainutkertaisuuden kiinnität erillisellä UNIQUE-rajoitteella, kuten yllä olevassa esimerkissä: yhteydet säilyvät, data pysyy rehellisenä, eikä ostajaa kielletä vaihtamasta sähköpostiaan.