Проверить ограничение - Check constraint

А проверить ограничение это тип ограничение целостности в SQL который определяет требование, которое должно выполняться каждым ряд в базе данных стол. Ограничение должно быть предикат. Он может относиться к одному столбцу или нескольким столбцы стола. Результатом предиката может быть либо ИСТИННЫЙ, ЛОЖНЫЙ, или же НЕИЗВЕСТНЫЙ, в зависимости от наличия NULL. Если предикат оценивается как НЕИЗВЕСТНЫЙ, то ограничение не нарушается, и строка может быть вставлена ​​или обновлена ​​в таблице. Это противоречит предикатам в КУДА статьи в ВЫБРАТЬ или же ОБНОВИТЬ заявления.

Например, в таблицу, содержащую продукты, можно добавить ограничение проверки, чтобы цена продукта и количество продукта были неотрицательными значениями:

 ЦЕНА> = 0

 КОЛИЧЕСТВО> = 0

Если бы этих ограничений не было, можно было бы получить отрицательную цену (-30 долларов) или количество (-3 единицы).

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

Определение

Каждое проверочное ограничение должно быть определено в СОЗДАТЬ ТАБЛИЦУ или же ИЗМЕНИТЬ ТАБЛИЦУ заявление с использованием синтаксиса:

 СОЗДАТЬ ТАБЛИЦУ table_name (..., ОГРАНИЧЕНИЕ constraint_name ПРОВЕРИТЬ ( предикат ),    ... )

 ИЗМЕНИТЬ ТАБЛИЦУ table_name    ДОБАВИТЬ ОГРАНИЧЕНИЕ constraint_name ПРОВЕРИТЬ ( предикат )

Если проверочное ограничение относится только к одному столбцу, можно указать ограничение как часть определения столбца.

 СОЗДАТЬ ТАБЛИЦУ table_name (    ...    имя_столбца тип ПРОВЕРИТЬ ( предикат ),    ... )

NOT NULL ограничение

А НЕТ НОЛЬ ограничение функционально эквивалентно следующему ограничению проверки с НЕ ПУСТО предикат:

 ПРОВЕРИТЬ (столбец НЕ ПУСТО)

Немного системы управления реляционными базами данных могут оптимизировать производительность, когда НЕ НОЛЬ синтаксис ограничения используется в отличие от ПРОВЕРИТЬ синтаксис ограничения, указанный выше.^[1]

Общие ограничения

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

Такие ограничения не совсем ограничения проверки таблицы скорее ограничения проверки строк. Поскольку эти ограничения обычно проверяются только при прямом обновлении строки (по соображениям производительности) и часто реализуются как подразумевается. ВСТАВЛЯТЬ или же ОБНОВИТЬ триггеры, ограничения целостности могут быть нарушены косвенными действиями, если бы не эти ограничения. Кроме того, в противном случае допустимые изменения этих записей были бы предотвращены ПРОВЕРИТЬ ограничение. Вот некоторые примеры опасных ограничений:

• ПРОВЕРИТЬ ((Выбрать считать(*) из счета куда счета.Пользовательский ИД = Пользовательский ИД) < 1000)
• ПРОВЕРИТЬ (dateInserted = ТЕКУЩАЯ ДАТА)
• ПРОВЕРИТЬ (countItems = RAND())

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

Рекомендации