Táblák, sorok és kulcsok

A jegyzék nyitva. A QUERY hologramot bont ki a munkaasztal fölött: több ezer rekord lebeg a levegőben egyenletes rácsban, és néhányuk között vékony, borostyánszínű fonalak feszülnek. Megérintesz egyet — megzendül, mint egy húr. Ez nem fájlok halmaza. Ez szövet.

Táblák, sorok, oszlopok

A relációs adatbázis olyan, mint egy rendezett katalógus: az adatok táblákba vannak szétosztva, és minden táblán belül oszlopok (milyen tulajdonságokat tárolunk) és sorok (a konkrét rekordok) vannak.

Vedd a vásárlók users tábláját: minden sor egy-egy régi földi vásárló, az oszlopok pedig leírják az id, full_name, email, country, city, signup_date adatait.

Hogy az azonos nevű embereket ne keverjük össze, minden sornak van elsődleges kulcsa (primary key) — egy egyedi azonosító, általában az id oszlop. Ezen keresztül más táblák idegen kulccsal (foreign key) hivatkozhatnak erre a sorra. Például az orders rendelésben van egy user_id — így emlékszik a rendelés a saját vásárlójára. A hologramon látott borostyánszínű fonalak éppen ezek a kulcs menti kapcsolatok.

QUERY: Amíg a kulcs ép — ép a fonal. Másfél évszázad telt el, és minden rendelés még mindig emlékszik a maga emberére.

Futtasd le a lekérdezést, és nézd meg, hogyan néznek ki a „Kotomarket” vásárlói — rekordok, amelyeket senki sem nyitott meg a régi Háló kora óta:

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:

Természetes vagy helyettesítő kulcs

Honnan származik az elsődleges kulcs? Két út van. A természetes kulcs olyan valós attribútum, amely amúgy is egyedi: a vásárló emailje, egy könyv ISBN-je, egy pénznemkód. A helyettesítő kulcs mesterséges azonosító, amelynek a külvilágban nincs jelentése: automatikus számozás vagy UUID. A „Kotomarket”-ben mindenhol helyettesítő id-kat használnak — és ez tankönyvi megoldás:

-- Helyettesítő kulcs: az adatbázis maga adja ki a következő számot (PostgreSQL)
CREATE TABLE users (
  id        BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email     TEXT NOT NULL UNIQUE,  -- a természetes jelölt mellette él UNIQUE-ként
  full_name TEXT NOT NULL
);

Miért így? Az elsődleges kulcs legfőbb tulajdonsága: nem szabad megváltoznia. A PK-ra más táblák idegen kulcsai hivatkoznak, és az érték megváltozása egyszerre vonná maga után az összes fonal frissítését — az orders-ben, az events-ben, mindenhol. „Örök” természetes attribútum pedig szinte nincs: az emberek emailt és vezetéknevet változtatnak, a telefonszámok átköltöznek, még az ISBN-eket is újra kiadják. A helyettesítő id sosem változik — épp azért, mert semmit sem jelent.

Bármely elsődleges kulccsal szembeni követelmény: egyedi, nem NULL, stabil. A természetes kulcsokat hagyd meg a kicsi, megváltoztathatatlan segédtábláknak — például a 'RUB' pénznemkódnak az ISO 4217-ből. Egy természetes jelölt, mint az email egyediségét pedig külön UNIQUE megszorítással rögzítsd, ahogy a fenti példában: a kapcsolatok megmaradnak, az adatok őszinték maradnak, és a vásárlónak sem tilos megváltoztatnia az emailjét.