Проверочное ограничение — это тип ограничения целостности в SQL , который определяет требование, которому должна соответствовать каждая строка в таблице базы данных . Ограничение должно быть предикатом . Он может относиться к одному или нескольким столбцам таблицы. Результатом предиката может быть TRUE, FALSEили UNKNOWN, в зависимости от наличия NULL . Если предикат имеет значение UNKNOWN, то ограничение не нарушается и строку можно вставить или обновить в таблице. Это противоречит предикатам в WHEREпредложениях SELECTили UPDATEутверждениях.
Например, в таблицу, содержащую продукты, можно добавить проверочное ограничение, чтобы цена продукта и количество продукта были неотрицательными значениями:
цена >= 0
количество >= 0
Если бы этих ограничений не было, можно было бы иметь отрицательную цену (-30 долларов США) или количество (-3 штуки).
Проверочные ограничения используются для обеспечения достоверности данных в базе данных и обеспечения целостности данных . Если они используются на уровне базы данных, приложения, использующие базу данных, не смогут добавлять недопустимые данные или изменять действительные данные, поэтому данные становятся недействительными, даже если само приложение принимает недопустимые данные.
Каждое проверочное ограничение должно быть определено в операторе CREATE TABLEили ALTER TABLEс использованием синтаксиса:
CREATE TABLE имя_таблицы ( ..., CONSTRAINT имя_ограничения CHECK ( предикат ), ...)
ALTER TABLE имя_таблицы ADD CONSTRAINT имя_ограничения CHECK ( предикат )
Если проверочное ограничение относится только к одному столбцу, можно указать ограничение как часть определения столбца.
CREATE TABLE имя_таблицы ( ... имя_столбца тип CHECK ( предикат ), ...)
Ограничение функционально эквивалентно следующему проверочному ограничению с предикатом:NOT NULLIS NOT NULL
ПРОВЕРИТЬ ( столбец НЕ NULL)
Некоторые системы управления реляционными базами данных способны оптимизировать производительность, если NOT NULLиспользуется синтаксис ограничений, а не CHECKсинтаксис ограничений, приведенный выше. [1]
Большинство систем управления базами данных ограничивают проверочные ограничения одной строкой с доступом к константам и детерминированным функциям, но не к данным в других таблицах или к данным, невидимым для текущей транзакции из-за изоляции транзакции .
Такие ограничения на самом деле не являются ограничениями проверки таблицы , а скорее ограничениями проверки строк . Поскольку эти ограничения обычно проверяются только при прямом обновлении строки (по соображениям производительности) и часто реализуются как подразумеваемые INSERTили UPDATEтриггеры, ограничения целостности могли бы быть нарушены косвенным действием, если бы не эти ограничения. Более того, тогда ограничение будет предотвращать допустимые в противном случае изменения этих записей CHECK. Некоторые примеры опасных ограничений включают в себя:
CHECK ((select count(*) from invoices where invoices.customerId = customerId) < 1000)CHECK (dateInserted = CURRENT_DATE)CHECK (countItems = RAND())Для обхода этих ограничений можно использовать определяемые пользователем триггеры . Хотя реализация аналогична, семантически ясно, что триггеры будут срабатывать только при прямом изменении таблицы и что ответственность за обработку косвенных важных изменений в других таблицах лежит на разработчике; ограничения, с другой стороны, должны быть «истинными во все времена», независимо от действий пользователя или недальновидности дизайнера.