🗄️ 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
);

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

Вопрос 3 из 20

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

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

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

Вопрос 4 из 20

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

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

Вопрос 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

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

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

Вопрос 8 из 20

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

customer_id bigint REFERENCES customers(id) ON DELETE CASCADE

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

Вопрос 9 из 20

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

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

Вопрос 10 из 20

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

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

Вопрос 11 из 20

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

UNIQUE (tenant_id, slug)

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

Вопрос 12 из 20

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

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

Вопрос 13 из 20

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

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

Вопрос 14 из 20

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

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

Вопрос 15 из 20

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

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

Вопрос 16 из 20

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

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

Вопрос 17 из 20

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

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

Вопрос 18 из 20

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

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

Вопрос 19 из 20

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

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

Вопрос 20 из 20

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

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

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

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

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

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