Базы данных: таблицы, ключи и зачем они бизнесу

Представьте небольшой интернет-магазин кофе и чая. Ему нужно помнить клиентов, товары, заказы и то, что лежит в каждом заказе. Реляционная база данных раскладывает это по таблицам. Документация PostgreSQL определяет таблицу как именованный набор строк: у всех строк одной таблицы одинаковый набор именованных столбцов, и у каждого столбца свой тип данных.

Строка — одна запись: один клиент или один заказ. Столбец — одно свойство всех записей: имя, город, e-mail, дата регистрации. В таблице клиентов ниже восемь строк и пять столбцов. Значение NULL означает «значение неизвестно или отсутствует»: у клиента не указан e-mail или город. Это не пустая строка и не ноль — к этому различию мы ещё вернёмся в уроках по SQL.

Таблицы объединяются в базу данных, а базой управляет СУБД — система управления базами данных. PostgreSQL работает как сервер: приложение (сайт, CRM, мобильный бэкенд) подключается к нему по сети, отправляет запросы и получает ответы. Сам сервер может обслуживать много подключений одновременно.

Первичный ключ (primary key) — столбец или набор столбцов, по которому строку можно однозначно найти. По документации PostgreSQL первичный ключ требует двух вещей одновременно: значения уникальны и не бывают NULL. Ключ у таблицы может быть только один, и база автоматически строит для него индекс, чтобы поиск по ключу был быстрым.

Почему бы не взять в качестве ключа имя или телефон? Имена повторяются: в магазине легко окажутся две клиентки по имени Айгерим. Телефон и e-mail меняются, а ещё их может не быть вовсе. Если на изменчивое значение ссылаются заказы, при смене номера придётся переписывать все связанные записи. Поэтому ключ обычно делают отдельным числовым столбцом id, который ничего не значит для людей и никогда не меняется.

CREATE TABLE clients (
    id         bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name       text NOT NULL,
    city       text,
    email      text UNIQUE,
    created_on date NOT NULL DEFAULT current_date
);

CREATE TABLE orders (
    id         bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    client_id  bigint NOT NULL REFERENCES clients (id),
    ordered_on date NOT NULL,
    status     text NOT NULL
               CHECK (status IN ('new', 'paid', 'shipped', 'cancelled')),
    promo_code text
);

• id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY — ключ; номера выдаёт база, вручную вписать его нельзя
• name text NOT NULL — имя обязательно, строка без имени не сохранится
• email text UNIQUE — два клиента с одним e-mail невозможны, но e-mail можно не указывать
• created_on date NOT NULL DEFAULT current_date — если дату не передали, база подставит сегодняшнюю

Ключ может состоять и из нескольких столбцов. В таблице позиций заказа order_items ключ — пара (order_id, product_id): один и тот же товар не может дважды попасть в один заказ отдельной строкой, вместо этого растёт количество.

В заказе не хранят имя и город клиента — только его номер в столбце client_id. Ограничение REFERENCES clients (id) превращает этот столбец во внешний ключ (foreign key): значение обязано совпадать с первичным ключом какой-то строки в таблице клиентов. Документация называет это ссылочной целостностью — в базе не появятся «осиротевшие» заказы.

Проверим, что база действительно следит за связью. Попробуем создать заказ клиенту с номером 99, которого нет, а затем удалить клиента, у которого есть заказы:

INSERT INTO orders (client_id, ordered_on, status)
VALUES (99, '2026-10-10', 'new');

-- ERROR:  insert or update on table "orders" violates foreign key constraint "orders_client_id_fkey"
-- DETAIL:  Key (client_id)=(99) is not present in table "clients".

DELETE FROM clients WHERE id = 1;

-- ERROR:  update or delete on table "clients" violates foreign key constraint "orders_client_id_fkey" on table "orders"
-- DETAIL:  Key (id)=(1) is still referenced from table "orders".

Что делать с зависимыми строками при удалении, решает проектировщик базы. По умолчанию удаление запрещено, пока на строку кто-то ссылается. Вариант ON DELETE CASCADE удаляет зависимые строки вместе с главной — он подходит, когда зависимая запись не существует сама по себе. В учебной базе так устроены позиции заказа: удалили заказ — удалились и его строки. А вот товары и заказы — независимые сущности, поэтому удалить товар, который кто-то уже купил, база не даст.

Обратите внимание на таблицу order_items. Один заказ содержит много товаров, а один товар встречается во многих заказах — это связь «многие ко многим». Её всегда раскладывают через промежуточную таблицу с двумя внешними ключами; ровно такую схему (products, orders, order_items) документация PostgreSQL разбирает в разделе об ограничениях. Цена в order_items хранится отдельно от каталога: каталог может подорожать, а сумма старого заказа меняться не должна.

Тип столбца — первое правило, которое база проверяет при записи: в столбец даты не попадёт строка «завтра», в числовой — «двенадцать». Для учебной базы хватает нескольких типов:

Типа часто недостаточно: цена — число, но отрицательной быть не должна. Для таких правил служат ограничения (constraints). Если запись их нарушает, PostgreSQL отклоняет её целиком и сообщает, какое правило сработало:

UPDATE orders SET status = 'delivered' WHERE id = 1;

-- ERROR:  new row for relation "orders" violates check constraint "orders_status_check"
-- DETAIL:  Failing row contains (1, 1, 2026-09-02, delivered, null).

INSERT INTO clients (name, email)
VALUES ('Aigerim S.', 'aigerim@example.com');

-- ERROR:  duplicate key value violates unique constraint "clients_email_key"
-- DETAIL:  Key (email)=(aigerim@example.com) already exists.

Одна тонкость: ограничение CHECK считается выполненным, если условие истинно или равно NULL. Поэтому weight_g integer CHECK (weight_g > 0) разрешает не указывать вес у кружки, но не даст записать отрицательный. Если значение обязательно, к CHECK добавляют NOT NULL. Документация советует: в большинстве схем большая часть столбцов должна быть NOT NULL.

Таблица в Excel или Google Sheets тоже состоит из строк и столбцов, и для старта этого часто хватает. Разница проявляется, когда данных и людей становится больше. Подробно о признаках этого момента — в статье «Когда пора уходить от Excel»; здесь — техническая сторона.

Транзакции стоит выделить отдельно. Документация PostgreSQL описывает их так: несколько шагов объединяются в одну операцию «всё или ничего», промежуточное состояние не видно другим пользователям, а при сбое ни один шаг не применяется. Для магазина это значит, что заказ не окажется оплаченным без списания товара со склада. Транзакциям посвящён отдельный урок траектории.

Всё, что описано выше, относится к реляционным базам: данные лежат в таблицах, связи задаются ключами, вопросы задаются на SQL. Самые распространённые реляционные СУБД в веб-разработке — PostgreSQL и MySQL. Как отмечает глоссарий MDN, большинство баз в веб-разработке устроены именно так, а базы с другой моделью данных называют NoSQL.

Это не соревнование: в одном проекте часто работают обе модели — PostgreSQL хранит заказы, Redis кеширует частые ответы. Для учёта, где важны связи и точность, начинают с реляционной базы. Когда и зачем добавлять NoSQL, разбирается в отдельном сравнении направления «Базы данных».

SQL — язык запросов к реляционным базам. Его главная особенность: вы описываете, какой результат нужен, а не как его получить. Не нужно писать «открой таблицу заказов, переберите строки, для каждой найди клиента» — достаточно назвать таблицы, связь и условие. Как именно читать данные, решает сама СУБД.

SELECT o.id, o.ordered_on, c.name, o.status
FROM orders AS o
JOIN clients AS c ON c.id = o.client_id
WHERE c.city = 'Almaty'
ORDER BY o.ordered_on;

Запрос читается почти как предложение: выбрать номер, дату, имя и статус из заказов, присоединив клиентов по client_id, где город — Almaty, отсортировав по дате. Каждую часть — SELECT, WHERE, ORDER BY, JOIN — мы разберём по шагам в следующих уроках на этой же учебной базе. Её можно поднять одной командой в Docker и повторить все примеры у себя.