Что такое constraint в базе данных

Что проверяют

Умеете ли вы переводить бизнес-правило в правило модели данных и понимаете ли, какие требования разумно закреплять в схеме, а какие оставлять приложению. Для аналитика это вопрос не про синтаксис, а про то, где живёт истина о данных.

Как отвечать

Ограничение это декларативное правило, которое СУБД проверяет при каждой записи и при нарушении отклоняет всю транзакцию. Основные виды: NOT NULL запрещает пустое значение; UNIQUE запрещает дубли; первичный ключ объединяет оба свойства и служит идентификатором строки; внешний ключ описывает связь и поведение при удалении или изменении родителя (запрет, каскад, обнуление); CHECK задаёт условие на значения строки. В отдельных СУБД есть ограничение на непересечение, удобное для интервалов дат.

Для аналитика важнее списка вывод: правило, вынесенное в схему, нельзя обойти ни новым сервисом, ни ручной правкой. Плата за это жёсткость. Правило вроде «у клиента один действующий договор» придётся либо выражать частичным уникальным индексом, либо оставлять приложению, и выбор надо делать осознанно, а не по привычке.

Где спотыкаются

Забывают про поведение пустых значений. В большинстве СУБД несколько пустых значений не считаются дублями, поэтому требование «адрес почты уникален» не мешает завести сколько угодно строк с незаполненным адресом. Формулировка в постановке должна закрывать этот случай отдельно.

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

Описывают связь между сущностями, не оговаривая поведение при удалении родителя. По умолчанию удаление запрещено, и сценарий «удалить клиента» перестаёт работать; поставленный не глядя каскад приводит к обратному, тихой потере связанной истории.