Таблицы, строки и ключи
Чему научишься
- отличать таблицы, строки и столбцы и объяснять, зачем каждой строке (обычно
id) - находить связи между таблицами по внешнему ключу:
orders.user_id → users.id - отличать суррогатный ключ (
IDENTITY, ) от натурального (email, ISBN) и обосновывать, почему первичный ключ не должен меняться - закреплять уникальность поля вроде
emailограничениемUNIQUE, не делая его первичным ключом
Опись открыта. КВЕРИ разворачивает над рабочим столом голограмму: тысячи записей повисают в воздухе ровной сеткой, и между некоторыми тянутся тонкие янтарные нити. Ты тянешься к одной — она звенит, как струна. Это не куча файлов. Это ткань.
Таблицы, строки, столбцы
Реляционная база похожа на аккуратный каталог: данные разложены по таблицам, а внутри каждой таблицы есть столбцы (какие свойства храним) и строки (конкретные записи).
Возьми таблицу покупателей users: каждая строка — один покупатель старой Земли, а столбцы описывают его id, full_name, email, country, city, signup_date.
Чтобы не путать людей с одинаковыми именами, у каждой строки есть (primary key) — уникальный идентификатор, обычно столбец id. Через него другие таблицы могут ссылаться на эту строку с помощью (foreign key). Например, в заказе orders есть user_id — так заказ помнит своего покупателя. Те самые янтарные нити на голограмме — это и есть связи по ключам.
КВЕРИ: Пока цел ключ — цела нить. Полтора века прошло, а каждый заказ всё ещё помнит своего человека.
Запусти запрос и посмотри, как выглядят покупатели «Котомаркета» — записи, которые никто не открывал со времён старой Сети:
| id | full_name | city | signup_date |
|---|---|---|---|
| 1 | Артём Волков | Санкт-Петербург | 2024-10-20 |
| 2 | Екатерина Алексеев | Екатеринбург | 2025-01-25 |
| 3 | Николай Никитин | Алматы | 2024-09-21 |
| 4 | Екатерина Иванов | Новосибирск | 2024-05-04 |
| 5 | Елена Петров | Казань | 2025-01-05 |
| 6 | Ирина Кузнецов | Новосибирск | 2024-09-12 |
Первичный ключ помогает безошибочно найти одну строку (обычно id). Внешний ключ связывает таблицы: например, orders.user_id → users.id показывает, чей это заказ. Дальше КВЕРИ развернёт перед тобой всю карту — пять таблиц целиком.
orders.user_id ссылается на первичный ключ users.id — так заказ помнит своего покупателя.Натуральный или суррогатный ключ
Откуда берётся ? Путей два. Натуральный ключ — реальный атрибут, который и так уникален: email покупателя, ISBN книги, код валюты. Суррогатный ключ — искусственный идентификатор без смысла во внешнем мире: автонумерация или . В «Котомаркете» везде используются суррогатные id — и это типовое решение:
-- Суррогатный ключ: база сама выдаёт следующий номер (PostgreSQL)
CREATE TABLE users (
id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
email TEXT NOT NULL UNIQUE, -- натуральный кандидат живёт рядом как UNIQUE
full_name TEXT NOT NULL
);
Почему так? Главное свойство первичного ключа: он не должен меняться. На PK ссылаются внешние ключи других таблиц, и смена значения потянула бы за собой обновление всех нитей сразу — в orders, в events, везде. А «вечных» натуральных атрибутов почти не бывает: люди меняют email и фамилии, телефоны переезжают, даже ISBN переиздают. Суррогатный id не меняется никогда — именно потому, что ничего не значит.
Требования к любому первичному ключу: уникален, не NULL, стабилен. Натуральные ключи оставь маленьким неизменяемым справочникам — например, коду валюты 'RUB' из ISO 4217. А уникальность натурального кандидата вроде email фиксируй отдельным ограничением UNIQUE, как в примере выше: связи сохраняются, и данные остаются честными, и менять почту покупателю не запрещено.
Забегаем вперёд: сам синтаксис создания таблиц и ограничений (CREATE TABLE, PRIMARY KEY, UNIQUE) — тема Главы 9. Здесь смотри на структуру ключа, а не на команду: что суррогатный id стал , а email живёт рядом как UNIQUE.
Вопрос с собеседования
Вопрос с собеседования: чем суррогатный ключ отличается от натурального и какой ты выберешь для таблицы пользователей?
Сильный ответ: натуральный — реальный уникальный атрибут (email, ISBN), суррогатный — искусственный идентификатор (IDENTITY-столбец или ). Для пользователей — суррогатный: не должен меняться, потому что на него ссылаются внешние ключи, а email люди меняют. Уникальность email при этом закрепляется отдельным UNIQUE-ограничением. Натуральный ключ оправдан в стабильных справочниках вроде кодов валют ISO 4217.