Что регулирует значения и форматы столбцов в реляционной базе данных
Что проверяют
Понимаете ли вы, что корректность данных обеспечивается схемой, а не только формой на экране. Для тестировщика это вопрос о том, где проходит последний рубеж проверки и что стоит дёргать в обход интерфейса.
Как отвечать
Отвечайте по слоям. Тип столбца задаёт множество допустимых значений и их формат: целое, numeric с точностью и масштабом, дата и время с зоной или без, строка ограниченной длины, логический, json, перечисление. Для строк к формату хранения добавляется правило сравнения и сортировки.
Ограничения задают всё остальное. NOT NULL запрещает отсутствие значения. DEFAULT подставляет значение, когда столбец не указан. CHECK описывает произвольное правило для значения или сочетания столбцов: положительная сумма, дата окончания не раньше даты начала, соответствие шаблону. UNIQUE и первичный ключ отвечают за неповторяемость, внешний ключ за существование связанной строки и за поведение при её удалении. Домен или пользовательский тип позволяет описать такое правило один раз и переиспользовать.
Поверх этого работают триггеры для правил, которые не выражаются декларативно, и проверки на стороне приложения, удобные пользователю, но ничего не гарантирующие.
Практический вывод: отправляйте значения мимо интерфейса, прямо запросом или вызовом сервиса, и смотрите, отвергнет ли их база. Проверяйте границы типа, длину строки, точность дробной части, а пустую строку отдельно от отсутствия значения.
Где спотыкаются
Считают пустую строку и отсутствие значения одним и тем же. NOT NULL пустую строку пропустит, поле окажется формально заполненным пустотой, и для запрета нужен ещё и CHECK.
Проверяют ограничения только через форму. Валидация на клиенте обходится прямым запросом, и тогда выясняется, что в схеме не запрещено ничего.
Из ограничений называют только ключи и NOT NULL, забывая DEFAULT и CHECK. Именно эти два отвечают на вопрос про значения и форматы напрямую.