Проверить ограничение
Проверочное ограничение — это тип ограничения целостности в 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 NULL
[ редактировать ]А NOT NULL ограничение функционально эквивалентно следующему проверочному ограничению с IS 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())
определяемые пользователем триггеры Для обхода этих ограничений можно использовать . Хотя реализация аналогична, семантически ясно, что триггеры будут срабатывать только при прямом изменении таблицы и что ответственность за обработку косвенных важных изменений в других таблицах лежит на разработчике; ограничения, с другой стороны, должны быть «истинными во все времена», независимо от действий пользователя или недальновидности дизайнера.
Ссылки
[ редактировать ]- ^ Документация PostgreSQL 13, Глава 5. Определение данных , Раздел 5.4.2. Ненулевые ограничения , Веб-сайт: https://www.postgresql.org/docs/13/ddl-constraints.html , по состоянию на 9 января 2021 г.