Tabulas, rindas un atslēgas

Apraksts atvērts. QUERY izvērš virs darbgalda hologrammu: tūkstošiem ierakstu uzkaras gaisā vienmērīgā režģī, un starp dažiem stiepjas tievi dzintarkrāsas pavedieni. Tu pastiep roku pret vienu — tas noskan kā stīga. Tā nav failu kaudze. Tas ir audums.

Tabulas, rindas, kolonnas

Relāciju datubāze ir kā kārtīgs katalogs: dati salikti pa tabulām, un katras tabulas iekšienē ir kolonnas (kādas īpašības glabājam) un rindas (konkrēti ieraksti).

Paņem pircēju tabulu users: katra rinda ir viens vecās Zemes pircējs, bet kolonnas apraksta viņa id, full_name, email, country, city, signup_date.

Lai nesajauktu cilvēkus ar vienādiem vārdiem, katrai rindai ir primārā atslēga (primary key) — unikāls identifikators, parasti kolonna id. Caur to citas tabulas var atsaukties uz šo rindu ar ārējās atslēgas (foreign key) palīdzību. Piemēram, pasūtījumā orders ir user_id — tā pasūtījums atceras savu pircēju. Tieši tie dzintarkrāsas pavedieni hologrammā ir saites pa atslēgām.

QUERY: Kamēr vesela atslēga — vesels pavediens. Pagājis pusotrs gadsimts, bet katrs pasūtījums joprojām atceras savu cilvēku.

Palaid vaicājumu un apskati, kā izskatās „Kotomarket” pircēji — ieraksti, kurus neviens nav atvēris kopš vecā Tīkla laikiem:

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:

Naturālā vai surogātatslēga

No kurienes rodas primārā atslēga? Ceļu ir divi. Naturālā atslēga ir reāls atribūts, kas jau tāpat ir unikāls: pircēja email, grāmatas ISBN, valūtas kods. Surogātatslēga ir mākslīgs identifikators bez nozīmes ārpasaulē: autonumerācija vai UUID. „Kotomarket” visur tiek izmantoti surogāta id — un tas ir tipisks risinājums:

-- Surogātatslēga: datubāze pati izsniedz nākamo numuru (PostgreSQL)
CREATE TABLE users (
  id        BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email     TEXT NOT NULL UNIQUE,  -- naturālais kandidāts dzīvo blakus kā UNIQUE
  full_name TEXT NOT NULL
);

Kāpēc tā? Galvenā primārās atslēgas īpašība: tā nedrīkst mainīties. Uz PK atsaucas citu tabulu ārējās atslēgas, un vērtības maiņa vilktu līdzi visu pavedienu atjaunināšanu uzreiz — orders, events, visur. Bet „mūžīgu” naturālu atribūtu gandrīz nemēdz būt: cilvēki maina email un uzvārdus, telefoni pārceļas, pat ISBN pārizdod. Surogāta id nemainās nekad — tieši tāpēc, ka neko nenozīmē.

Prasības jebkurai primārajai atslēgai: unikāla, ne NULL, stabila. Naturālās atslēgas atstāj maziem nemainīgiem uzziņu sarakstiem — piemēram, valūtas kodam 'RUB' no ISO 4217. Bet tāda naturālā kandidāta kā email unikalitāti fiksē ar atsevišķu UNIQUE ierobežojumu, kā piemērā augstāk: saites saglabājas, dati paliek godīgi, un pircējam pastu mainīt nav aizliegts.