Базы данных
Реляционная модель: тест с множественным выбором
Суть Синтез с множественным выбором по юниту реляционной модели: keys, нормальные формы, JSONB vs side-таблица, foreign key at scale, TOAST и изменение схемы без простоя.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов, проходящих сквозь весь юнит. Ни один не про заучивание определения — каждый это решение по дизайну схемы под реальными ограничениями, где неверный выбор оплачивается на миграции, а не на проектировании.
Цель
Убедитесь, что вы связываете спину юнита: keys и constraints, нормальные формы vs намеренная денормализация, JSONB vs типизированные колонки vs side-таблицы, экономика foreign key на масштабе, физическое хранение и то, как схема меняется без простоя.
Викторина
Completed
В таблице customers email используется как PRIMARY KEY. Маркетинг теперь хочет, чтобы пользователи могли менять email. В чём корневая проблема и стандартное решение?
Heads-up Ширина индекса не проблема; TEXT email индексируется нормально. Проблема в изменяемости: меняющийся PK должен каскадировать через каждый ссылающийся FK. Хеш всё равно выводится из изменяемого email.
Heads-up Postgres каскадирует смену PK только если каждый FK объявлен ON UPDATE CASCADE, и даже тогда переписывание затрагивает каждую дочернюю строку под блокировкой. Устойчивый ответ — никогда не класть изменяемое значение в PK.
Heads-up Дублирующая гарантия уникальности не убирает проблему изменяемости — email всё ещё PK, поэтому его смена всё ещё каскадирует. Email нужно вывести из роли PK полностью.
Викторина
Completed
Таблица хранит `orders(order_id, customer_id, customer_city)`, где primary key — только `order_id`. Какую нормальную форму она нарушает и что ломается в продакшене?
Heads-up Частичная зависимость 2NF применима только к составным primary key. Здесь order_id один — это PK, так что нарушать нечего.
Heads-up Название города — единственное атомарное значение. 1NF про повторяющиеся группы и многозначные ячейки, а не про транзитивные зависимости.
Heads-up Это валидная денормализация только если дубль согласуется чем-то (триггер, job) И намерение — снимок на момент времени. Здесь это несогласованная транзитивная зависимость — ровно тот режим отказа, что закрывает 3NF.
Викторина
Completed
Маркетплейсу нужны свободные теги товаров, поддерживающие четыре запроса: показать теги товара, перечислить все товары с тегом X, посчитать товары по тегу и переименовать тег глобально. Какая форма хранения дёшево покрывает все четыре на масштабе?
Heads-up Массив тянет «теги этого товара» и (через GIN) «товары с тегом X», но агрегация по тегу дорога, а глобальное переименование значит переписать каждую строку, содержащую тег. Два из четырёх запросов проваливаются на масштабе.
Heads-up JSONB здесь строго хуже массива — выше накладные на парсинг, нет уникальности или FK на канонический список тегов — и всё равно не может дёшево посчитать по тегу или переименовать глобально.
Heads-up Это дублирует факт тега по заказам без согласования, воссоздавая проблему расхождения 3NF, и всё равно не даёт ни счёта по тегу, ни переименования одной строкой.
Викторина
Completed
Senior-инженер предлагает отключить foreign keys по всей типичной B2B SaaS-схеме (таблицы до 100M строк), чтобы «улучшить производительность записи». Как читать это предложение?
Heads-up Проверка FK ~5-50 мкс на строку, пренебрежимо для SaaS до 100M строк. «Hyperscale-конторы отключают FK» — это масштабное исключение, а не общая best practice.
Heads-up Enforcement на уровне приложения реализуется непоследовательно и ломается при рефакторингах и между сервисами. FK — единственная граница, которую каждый вызывающий получает бесплатно.
Heads-up Индекс на FK-колонке помогает производительности запросов, а не стоимости проверки FK, и не отвечает на реальный вопрос, оправдано ли отключение constraint на этом масштабе. Не оправдано.
Викторина
Completed
`SELECT * FROM events ORDER BY created_at DESC LIMIT 100` на таблице в 50M строк с индексом на created_at в 3× медленнее ожидаемого. В таблице JSONB-колонка payload в среднем 8KB. Наиболее вероятная причина и исправление?
Heads-up B-tree на created_at поддерживает обратный index scan для ORDER BY ... DESC LIMIT 100; скан дёшев. Стоимость — это TOAST-fetch на строку от SELECT *.
Heads-up Селективный индекс, возвращающий 100 строк, использует index scan на таблице любого размера. Выбор планировщика определяет селективность, а не число строк.
Heads-up JSONB можно возвращать в любом запросе. Особого медленного пути нет; лишняя стоимость — доставание TOAST-payload для каждой строки.
Викторина
Completed
Колонку `user_name` нужно превратить в `display_name` на таблице в 50M строк, общей для многих сервисов, без простоя. Какой подход верный и почему однострочный rename неверен?
Heads-up Rename — это только метаданные и мгновенно, но он атомарно ломает каждого потребителя, всё ещё запрашивающего user_name. На общей схеме с многими сервисами, которые не могут развернуться одновременно, это немедленный сбой.
Heads-up View облегчает чтения, но записи через него требуют INSTEAD OF триггеров или правил обновляемого view, и это лишь переходный мост — не замена полной миграции expand-then-contract.
Heads-up Простой может быть приемлем для внутреннего инструмента, но задача требует zero downtime, и окно всё равно заставляет всех потребителей развернуть обновлённый код одновременно. Expand-then-contract — это ответ без простоя.
Итог
Сквозная линия юнита — одна дисциплина решений: кладите identity в неизменяемый surrogate key и охраняйте business keys через UNIQUE NOT NULL; нормализуйте до 3NF, чтобы две строки не могли разойтись, и денормализуйте только с явным согласованием; тянитесь к side-таблице в момент, когда запрашиваете с другой стороны; держите FK-constraints, пока измеренное ограничение шардинга или каскада не вынудит иначе; помните, что физическое хранение (TOAST, page layout) делает SELECT * дорогим на широких строках; и меняйте живую схему через expand-then-contract, никогда не ломая на месте. Каждый ответ здесь сводится к «проектируй под запросы и жизненный цикл, а не под первый insert».