Tabele, wiersze i klucze

Inwentarz otwarty. QUERY rozwija nad biurkiem hologram: tysiące rekordów zawisają w powietrzu równą siatką, a między niektórymi ciągną się cienkie bursztynowe nici. Dotykasz jednej — dźwięczy jak struna. To nie sterta plików. To splot.

Tabele, wiersze, kolumny

Baza relacyjna przypomina porządny katalog: dane są rozłożone na tabele, a wewnątrz każdej tabeli są kolumny (jakie właściwości przechowujemy) i wiersze (konkretne rekordy).

Weź tabelę kupujących users: każdy wiersz to jeden kupujący ze starej Ziemi, a kolumny opisują jego id, full_name, email, country, city, signup_date.

Żeby nie mylić ludzi o tych samych imionach, każdy wiersz ma klucz główny (primary key) — unikalny identyfikator, zwykle kolumnę id. Dzięki niemu inne tabele mogą odwoływać się do tego wiersza za pomocą klucza obcego (foreign key). Na przykład w zamówieniu orders jest user_id — tak zamówienie pamięta swojego kupującego. Bursztynowe nici na hologramie to właśnie powiązania po kluczach.

QUERY: Dopóki klucz jest cały, nić też trzyma. Minęło półtora wieku, a każde zamówienie wciąż pamięta swojego człowieka.

Uruchom zapytanie i zobacz, jak wyglądają kupujący „Kotomarketu” — rekordy, których nikt nie otwierał od czasów starej Sieci:

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:

Klucz naturalny czy sztuczny

Skąd bierze się klucz główny? Są dwie drogi. Klucz naturalny to rzeczywisty atrybut, który i tak jest unikalny: email kupującego, ISBN książki, kod waluty. Klucz sztuczny to identyfikator wymyślony, bez znaczenia poza bazą: numer generowany automatycznie albo UUID. W „Kotomarkecie” wszędzie używane są sztuczne id — i to typowe rozwiązanie:

-- Klucz sztuczny: baza sama wydaje kolejny numer (PostgreSQL)
CREATE TABLE users (
  id        BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email     TEXT NOT NULL UNIQUE,  -- naturalny kandydat żyje obok jako UNIQUE
  full_name TEXT NOT NULL
);

Dlaczego tak? Najważniejsza właściwość klucza głównego: nie powinien się zmieniać. Do PK odwołują się klucze obce innych tabel, a zmiana wartości pociągnęłaby za sobą aktualizację wszystkich nici naraz — w orders, w events, wszędzie. A „wiecznych” atrybutów naturalnych prawie nie ma: ludzie zmieniają email i nazwiska, telefony przechodzą do kogoś innego, nawet ISBN bywa wznawiany. Sztuczne id nie zmienia się nigdy — właśnie dlatego, że nic nie znaczy.

Wymagania wobec każdego klucza głównego: unikalny, nie NULL, stabilny. Klucze naturalne zostaw niewielkim, stabilnym słownikom — na przykład kodowi waluty 'RUB' z ISO 4217. A unikalność naturalnego kandydata takiego jak email utrwal osobnym ograniczeniem UNIQUE, jak w przykładzie powyżej: powiązania zostają zachowane, dane pozostają rzetelne, a zmiana adresu e-mail kupującego nie jest zabroniona.