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

Проверочное ограничение — это тип ограничения целостности в SQL , который определяет требование, которому должна соответствовать каждая строка в таблице базы данных . Ограничение должно быть предикатом . Он может относиться к одному или нескольким столбцам таблицы . Результатом предиката может быть либо TRUE, FALSE, или UNKNOWN, в зависимости от наличия NULL . Если предикат имеет значение UNKNOWN, то ограничение не нарушается и строку можно вставить или обновить в таблице. Это противоречит предикатам в WHERE положения в SELECT или UPDATE заявления.

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

price >= 0

quantity >= 0

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

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

Определение

Каждое проверочное ограничение должно быть определено в CREATE TABLE или ALTER TABLE заявление с использованием синтаксиса:

CREATE TABLE table_name (
    ...,
    CONSTRAINT constraint_name CHECK ( predicate ),
    ...
)

ALTER TABLE table_name
   ADD CONSTRAINT constraint_name CHECK ( predicate )

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

CREATE TABLE table_name (
    ...
    column_name type CHECK ( predicate ),
    ...
)

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

А NOT NULL ограничение функционально эквивалентно следующему проверочному ограничению с IS NOT NULL предикат:

CHECK (column IS NOT NULL)

Некоторые системы управления реляционными базами данных способны оптимизировать производительность, когда NOT NULL синтаксис ограничений используется в отличие от CHECK синтаксис ограничения, указанный выше.

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

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

Такие ограничения на самом деле не являются ограничениями проверки таблицы , а скорее ограничениями проверки строк . Поскольку эти ограничения обычно проверяются только при непосредственном обновлении строки (из соображений производительности) и часто реализуются так, как подразумевается. INSERT или UPDATE триггеров, ограничения целостности могли бы быть нарушены косвенными действиями, если бы не эти ограничения. Более того, действительные в противном случае изменения этих записей будут предотвращены CHECK ограничение. Некоторые примеры опасных ограничений включают в себя:

• CHECK ((select count(*) from invoices where invoices.customerId = customerId) < 1000)
• CHECK (dateInserted = CURRENT_DATE)
• CHECK (countItems = RAND())

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