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

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

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

PRICE>= 0

QUANTITY>= 0

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

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

Содержание

• 1 Определение
• 2 Ограничение NOT NULL
• 3 Общие ограничения
• 4 Ссылки

Определение

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

CREATE TABLE имя_таблицы (..., CONSTRAINT имя_ограничения CHECK (предикат),...)

ALTER TABLE имя_таблицы ADD CONSTRAINT имя_ограничения CHECK (предикат)

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

CREATE TABLE имя_таблицы (... имя_столбца тип CHECK (предикат),...)

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

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

CHECK (столбец IS NOT NULL)

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

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

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

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

• CHECK ((выберите count (*) из счетов-фактур, где invoices.customerId = customerId) < 1000)
• CHECK (dateInserted = CURRENT_DATE)
• CHECK (countItems = RAND ())

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

Ссылки

1. ^Документация PostgreSQL 8.3devel, Глава 5. Определение данных, раздел 5.3.2. Ограничения Not-Null, веб-сайт: http://developer.postgresql.org/pgdocs/postgres/ddl-constraints.html, дата обращения 5 мая 2007 г.