Схема «Котомаркета»
Чему научишься
- находить нужную таблицу среди пяти в «Котомаркете»:
users,products,orders,order_items,events - читать : определять связи (1:N, N:M, 1:1) по тому, где лежит
- разворачивать связь «многие ко многим» через с двумя FK — как
order_itemsсorder_id+product_id - объяснять, почему состав заказа нельзя хранить строкой id прямо в
orders
Сегодня КВЕРИ выводит на главный стол всю опись разом. Пять светящихся плоскостей повисают в воздухе и медленно вращаются — карта уцелевшего мира. Рядом мерцает журнал консервации, приложенный к снимку, и одна строка в нём подчёркнута: «Передаю пять таблиц и след шестой. — К.» Ты пересчитываешь плоскости. Ровно пять. Где след?
КВЕРИ: Не отвлекайся на следы. Сначала выучи эти пять так, чтобы находить дорогу с закрытыми глазами, — остальное архив покажет сам, когда сочтёт тебя готовым.

Пять таблиц «Котомаркета»
Дальше мы будем работать с этой базой — снимком интернет-магазина за 2024 год. Держи её как карту магазина: кто пришёл, что лежит на витрине, что купили и какие действия совершали до покупки.
| Таблица | Что хранит |
|---|---|
users | покупателей: id, имя, город и дату регистрации |
products | товары витрины: id, название, категорию, цену и остаток |
orders | заказы: id, user_id, дату, статус и сумму |
order_items | состав заказов: какой товар, сколько штук и по какой цене |
events | поведенческие события: просмотры, добавления в корзину и покупки |
Связи читаются так: один user → много orders; один order → много order_items; один product → много order_items. Если потеряешься, открывай схему справа — она как план торгового зала.
Заглянем в таблицу заказов: в каждой строке есть user_id — ссылка на покупателя. Так одна таблица связывается с другой, и карта перестаёт быть пятью отдельными островами.
user_id:Как читать ER-диаграмму
Карту, которую развернул КВЕРИ, в индустрии называют ER-диаграммой (entity–relationship): прямоугольники — таблицы, линии между ними — связи по внешним ключам. Самое важное на линии — : сколько строк с одной стороны соответствует скольким с другой.
- 1:N, один-ко-многим — самая частая связь. Один покупатель — много заказов. Внешний ключ всегда лежит на стороне «многих»:
user_idхранится вorders, а не наоборот. Это и есть правило чтения: нашёл FK — нашёл сторону N. - N:M, многие-ко-многим — в одном заказе много товаров, и один товар встречается во многих заказах. Напрямую такую связь в реляционной базе выразить нельзя: некуда положить. Её разворачивают через — у нас это
order_items. Каждая её строка несёт пару ссылокorder_id+product_idи превращает одну связь N:M в две связи 1:N. Бонус: у самой связи появляются атрибуты — количество штук и цена на момент покупки. - 1:1, один-к-одному — встречается реже: например, тяжёлые или приватные поля выносят в отдельную таблицу с тем же ключом.
-- Развязка N:M в действии: пары «заказ — товар» из order_items
SELECT order_id, product_id, quantity
FROM order_items
LIMIT 6;
Грабли: хранить состав заказа прямо в orders — строкой '7,12,3' или массивом идентификаторов. Такие данные нельзя защитить , честно посчитать или соединить с витриной без акробатики. Видишь связь «многие ко многим» — создавай с двумя внешними ключами, как order_items.
Вопрос с собеседования
Вопрос с собеседования: как в реляционной базе реализовать связь «многие ко многим»?
Сильный ответ: через с двумя внешними ключами на связываемые таблицы — как order_items с order_id и product_id: она превращает N:M в две связи 1:N. Заодно в ней хранят атрибуты самой связи — количество, цену на момент покупки. Первичный ключ такой таблицы — либо составной из двух FK, либо суррогатный id.