Tabuľky, riadky a kľúče

Súpis je otvorený. QUERY rozvinie nad pracovným stolom hologramu: tisíce záznamov visia vo vzduchu rovnomernou mriežkou a medzi niektorými sa ťahajú tenké jantárové nite. Načiahneš sa po jednej — zazvoní ako struna. Toto nie je kopa súborov. Toto je tkanivo.

Tabuľky, riadky, stĺpce

Relačná databáza sa podobá na úhľadný katalóg: dáta sú rozložené do tabuliek a vnútri každej tabuľky sú stĺpce (aké vlastnosti uchovávame) a riadky (konkrétne záznamy).

Zober si tabuľku zákazníkov users: každý riadok je jeden zákazník starej Zeme a stĺpce opisujú jeho id, full_name, email, country, city, signup_date.

Aby sa nepomýlili ľudia s rovnakými menami, má každý riadok primárny kľúč (primary key) — jedinečný identifikátor, zvyčajne stĺpec id. Cez neho sa iné tabuľky môžu na tento riadok odkazovať pomocou cudzieho kľúča (foreign key). Napríklad objednávka orders má user_id — tak si objednávka pamätá svojho zákazníka. Práve tie jantárové nite na hologramu sú väzby cez kľúče.

QUERY: Kým drží kľúč — drží aj niť. Poldruha storočia prešlo a každá objednávka si stále pamätá svojho človeka.

Spusti dotaz a pozri sa, ako vyzerajú zákazníci «Kotomarketu» — záznamy, ktoré nikto neotvoril od čias starej Siete:

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:

Prirodzený alebo náhradný kľúč

Odkiaľ sa berie primárny kľúč? Cesty sú dve. Prirodzený kľúč je reálny atribút, ktorý je aj tak jedinečný: email zákazníka, ISBN knihy, kód meny. Náhradný kľúč je umelý identifikátor bez významu vo vonkajšom svete: autočíslovanie alebo UUID. V «Kotomarkete» sa všade používajú náhradné id — a je to typové riešenie:

-- Náhradný kľúč: databáza sama vydáva ďalšie číslo (PostgreSQL)
CREATE TABLE users (
  id        BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email     TEXT NOT NULL UNIQUE,  -- prirodzený kandidát žije vedľa ako UNIQUE
  full_name TEXT NOT NULL
);

Prečo tak? Hlavná vlastnosť primárneho kľúča: nesmie sa meniť. Na PK sa odkazujú cudzie kľúče iných tabuliek a zmena hodnoty by so sebou potiahla aktualizáciu všetkých nití naraz — v orders, v events, všade. A «večné» prirodzené atribúty takmer neexistujú: ľudia menia email aj priezviská, telefóny sa presúvajú, dokonca aj ISBN sa znova vydáva. Náhradné id sa nemení nikdy — práve preto, že nič neznamená.

Požiadavky na akýkoľvek primárny kľúč: jedinečný, nie NULL, stabilný. Prirodzené kľúče nechaj malým nemenným číselníkom — napríklad kódu meny 'RUB' z ISO 4217. A jedinečnosť prirodzeného kandidáta ako email zafixuj samostatným obmedzením UNIQUE, ako v príklade vyššie: väzby sa zachovajú, dáta zostanú poctivé a zmeniť zákazníkovi mail nie je zakázané.