Базы данных
Реляционная модель: тест с краткими ответами
Припоминание сильнее перечитывания. Для каждого вопроса проговорите или запишите полный ответ по памяти, прежде чем открыть модельный — именно усилие извлечения закрепляет инстинкты дизайна схемы.
Восстановите ключевые механизмы юнита — keys, 3NF, правило выбора JSONB, экономику FK, физическое хранение и изменение схемы без простоя — не подсматривая в уроки.
- 01В чём разница между candidate key и primary key, и почему дефолт 2026 года — это surrogate primary key плюс UNIQUE NOT NULL на business key?
- 02Почему 3NF — это нормальная форма по умолчанию для продакшена, и какие два легитимных направления её покинуть?
- 03Сформулируйте правило выбора между JSONB, типизированной колонкой и side-таблицей с примером каждого.
- 04Что foreign key реально стоит, что он покупает, и при каких специфичных условиях его отключение — оправданный инженерный выбор?
- 05Объясните механизм TOAST и два следствия для дизайна схемы и запросов, которые он несёт по производительности.
- 06Опишите паттерн expand-then-contract и объясните, почему он нужен для переименования колонки на большой общей таблице без простоя.
Если вы восстановили каждый ответ по памяти, вы держите спину юнита: identity живёт в неизменяемом surrogate key, а business keys охраняются через UNIQUE NOT NULL; 3NF не даёт двум строкам разойтись, а денормализация — это измеренное исключение с явным согласованием; выбор JSONB/типизированная колонка/side-таблица целиком определяется тем, как вы запрашиваете значение; foreign keys — это дешёвая страховка, которую вы держите, пока специфичное ограничение масштаба не вынудит иначе; физическое хранение (TOAST, page alignment) делает SELECT * на широких строках дорогим; а живая схема меняется через expand-then-contract, никогда не ломаясь на месте.