Tabulky, řádky a klíče

Soupis je otevřený. QUERY rozvine nad pracovním stolem hologram: tisíce záznamů visí ve vzduchu v rovné mřížce a mezi některými se táhnou tenké jantarové nitky. Sáhneš po jedné — zazní jako struna. Tohle není hromada souborů. Tohle je tkanina.

Tabulky, řádky, sloupce

Relační databáze připomíná pečlivý katalog: data jsou rozložena do tabulek a uvnitř každé tabulky jsou sloupce (jaké vlastnosti uchováváme) a řádky (konkrétní záznamy).

Vezmi tabulku zákazníků users: každý řádek je jeden zákazník staré Země a sloupce popisují jeho id, full_name, email, country, city, signup_date.

Aby se nepletli lidé se stejnými jmény, má každý řádek primární klíč (primary key) — jedinečný identifikátor, obvykle sloupec id. Skrze něj na tento řádek mohou jiné tabulky odkazovat pomocí cizího klíče (foreign key). Například objednávka orders má user_id — tak si objednávka pamatuje svého zákazníka. Ty jantarové nitky na hologramu jsou právě vazby přes klíče.

QUERY: Dokud drží klíč, drží nitka. Půldruhého století uplynulo, a každá objednávka si pořád pamatuje svého člověka.

Spusť dotaz a podívej se, jak vypadají zákazníci «Kotomarketu» — záznamy, které od dob staré Sítě nikdo neotevřel:

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:

Přirozený, nebo surogátní klíč

Odkud se primární klíč bere? Cesty jsou dvě. Přirozený klíč je reálný atribut, který je sám o sobě jedinečný: email zákazníka, ISBN knihy, kód měny. Surogátní klíč je umělý identifikátor bez významu ve vnějším světě: automatické číslování nebo UUID. V «Kotomarketu» se všude používají surogátní id — a je to typové řešení:

-- Surogátní klíč: databáze sama vydává další číslo (PostgreSQL)
CREATE TABLE users (
  id        BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email     TEXT NOT NULL UNIQUE,  -- natural candidate lives alongside it as UNIQUE
  full_name TEXT NOT NULL
);

Proč zrovna takhle? Hlavní vlastnost primárního klíče: nesmí se měnit. Na PK odkazují cizí klíče jiných tabulek a změna hodnoty by za sebou táhla aktualizaci všech nitek najednou — v orders, v events, všude. A «věčné» přirozené atributy skoro neexistují: lidé mění email i příjmení, telefony se přidělují jinam, dokonce i ISBN se znovu vydávají. Surogátní id se nemění nikdy — právě proto, že nic neznamená.

Požadavky na jakýkoli primární klíč: jedinečný, ne NULL, stabilní. Přirozené klíče nech malým neměnným číselníkům — třeba kódu měny 'RUB' z ISO 4217. A jedinečnost přirozeného kandidáta jako email zajisti zvlášť omezením UNIQUE, jako v příkladu výše: vazby zůstanou zachované, data zůstanou poctivá a měnit zákazníkovi email se nezakazuje.