🗄️ SQL и базы данных · 20 вопросов · ~34 мин · ⏱ Таймер 34:00 · Лёгкий ·

Ключи и ограничения

Ограничение ценится не названием, а тем, какую ошибочную строку оно не позволит сохранить. В тесте нужно выбрать ключ для устойчивой идентификации, проследить действие внешней ссылки, различить уникальность и первичный ключ, увидеть поведение NULL и написать CHECK, который действительно закрывает бизнес-правило, а не создаёт иллюзию защиты.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выбери один ответ из четырёх. В тесте 20 вопросов и 34 минут. После завершения откроются общий процент, четыре тематические шкалы, правильные ответы и разбор каждого задания.

Вопрос 1 из 20

Какое свойство обязательно для PRIMARY KEY?

Значение может повторяться, но не более двух раз Столбец должен быть автоинкрементным и иметь числовой тип Значение уникально и не равно NULL Ключ автоматически сортирует физические строки

Вопрос 2 из 20

Почему email не всегда удачный первичный ключ пользователя?

CREATE TABLE users (
  email text PRIMARY KEY,
  name text NOT NULL
);

Адрес может измениться, а на ключ ссылаются другие таблицы Email невозможно сделать уникальным Текстовый PRIMARY KEY не может содержать символы вроде @ и точки Строковый ключ нельзя использовать во внешнем ключе другой таблицы

Вопрос 3 из 20

Что идентифицирует составной первичный ключ?

CREATE TABLE user_roles (
  user_id bigint,
  role_id bigint,
  PRIMARY KEY (user_id, role_id)
);

Каждый столбец составного ключа обязан быть уникален отдельно Он допускает NULL в одной части Первый столбец идентифицирует строку, второй нужен только для сортировки Уникальной должна быть комбинация столбцов

Вопрос 4 из 20

Какой ключ лучше идентифицирует строку позиции заказа, если номер позиции уникален только внутри заказа?

PRIMARY KEY (qty) PRIMARY KEY (product_id) PRIMARY KEY (line_no) PRIMARY KEY (order_id, line_no)

Вопрос 5 из 20

Зачем сохранять UNIQUE(passport_number), если у строки уже есть id PRIMARY KEY?

Чтобы бизнес-идентификатор не повторялся, оставаясь отдельным от технического id Чтобы любой запрос по таблице выбирал UNIQUE вместо первичного ключа Чтобы у строки было два равноправных первичных ключа для разных запросов Чтобы разрешить несколько строк с пустым номером паспорта

Вопрос 6 из 20

Что запретит внешний ключ orders.customer_id → customers.id?

FOREIGN KEY (customer_id) REFERENCES customers(id)

Заказ со ссылкой на несуществующего клиента Два заказа одного клиента Удаление любого заказа Повтор customer_id

Вопрос 7 из 20

Где обычно хранится внешний ключ в связи «один клиент — много заказов»?

В customers как список всех order_id В orders как customer_id В названии таблицы В отдельном индексе без столбца

Вопрос 8 из 20

Что произойдёт при ON DELETE CASCADE?

customer_id bigint REFERENCES customers(id) ON DELETE CASCADE

Удаление дочерней строки запустит каскадное удаление родительской Удалятся связанные дочерние строки Внешний ключ дочерней таблицы автоматически станет UNIQUE В дочерних строках внешний ключ заменится на NULL независимо от его типа

Вопрос 9 из 20

Когда ON DELETE SET NULL невозможно применить корректно?

Когда родитель имеет PRIMARY KEY Когда ссылающийся столбец объявлен NOT NULL Когда внешний ключ индексирован Когда таблицы в одной схеме

Вопрос 10 из 20

Какое действие разумнее для финансового платежа при попытке удалить заказ, если запись платежа должна сохраняться для аудита?

Удалять платёж каскадно вместе с заказом, полагаясь на внешний аудит Запретить удаление заказа или использовать архивирование вместо физического удаления Переназначать payment.order_id на технический заказ 0 через ON DELETE SET DEFAULT Убрать внешний ключ и разрешить приложению самостоятельно поддерживать связь

Вопрос 11 из 20

Что гарантирует UNIQUE (tenant_id, slug)?

UNIQUE (tenant_id, slug)

Оба столбца становятся PRIMARY KEY tenant_id уникален сам по себе Комбинация tenant_id и slug не повторяется slug уникален во всей базе

Вопрос 12 из 20

Почему два отдельных UNIQUE на user_id и project_id неверны для таблицы участия?

Два отдельных UNIQUE создают лишние индексы, но не меняют допустимые связи Для связи многие-ко-многим достаточно CHECK(user_id <> project_id) Они запрещают одному пользователю несколько проектов и проекту несколько пользователей UNIQUE применим только к одному числовому id, но не к внешним ключам

Вопрос 13 из 20

Может ли обычный UNIQUE-столбец PostgreSQL по умолчанию содержать несколько NULL?

Только если столбец PRIMARY KEY Нет: PostgreSQL по умолчанию считает все NULL равными для UNIQUE Да, NULL по умолчанию считаются различными для уникальности Нет: UNIQUE допускает только один NULL во всём столбце

Вопрос 14 из 20

Как запретить два активных профиля одного пользователя, но разрешить исторические неактивные записи?

CREATE INDEX ON profiles(active); CHECK (active = false); CREATE UNIQUE INDEX ON profiles(user_id); CREATE UNIQUE INDEX ON profiles(user_id) WHERE active;

Вопрос 15 из 20

Что конфликтует с UNIQUE(email), если email NOT NULL?

Изменение имени пользователя Две строки с одинаковым адресом Строка с новым id Две строки с разными адресами

Вопрос 16 из 20

Какой CHECK запрещает отрицательную цену и разрешает ноль?

CHECK (price >= 0) CHECK (price BETWEEN 1 AND NULL) CHECK (price > 0) CHECK (price <> NULL)

Вопрос 17 из 20

Почему CHECK (price > 0) сам по себе может пропустить NULL?

Результат UNKNOWN не считается нарушением; нужен ещё NOT NULL NULL неявно преобразуется в 1, и условие price > 0 становится истинным CHECK пропускает NULL, потому что числовые сравнения в ограничениях не выполняются CHECK проверяется только при SELECT

Вопрос 18 из 20

Как выразить правило «end_at не раньше start_at», допуская ещё не заданный end_at?

CHECK (end_at IS NULL OR end_at >= start_at) CHECK (end_at = NULL) CHECK (end_at IS NOT NULL AND end_at >= start_at) CHECK (start_at > end_at)

Вопрос 19 из 20

Какое ограничение требует reason только при status = 'cancelled'?

CHECK (status='cancelled' AND reason IS NOT NULL) CHECK (status IS NULL) CHECK (reason='cancelled') CHECK (status<>'cancelled' OR reason IS NOT NULL)

Вопрос 20 из 20

Почему в PostgreSQL нельзя выразить межтабличное правило через CHECK с подзапросом?

Запрет действует только для таблиц без первичного ключа Подзапрос допустим в CHECK, если возвращает ровно одно boolean-значение Подзапрос можно использовать после объявления ограничения DEFERRABLE Подзапросы в CHECK не допускаются; нужно выбрать другое ограничение или транзакционный механизм

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу