Comprobar restricción - Check constraint

Una restricción de verificación es un tipo de restricción de integridad en SQL que especifica un requisito que debe cumplir cada fila en una tabla de base de datos . La restricción debe ser un predicado . Puede hacer referencia a una sola columna o a varias columnas de la tabla. El resultado del predicado puede ser TRUE , FALSE o UNKNOWN , dependiendo de la presencia de valores NULL . Si el predicado se evalúa en UNKNOWN , entonces la restricción no se infringe y la fila se puede insertar o actualizar en la tabla. Esto es contrario a los predicados en WHERE cláusulas SELECT o UPDATE declaraciones.

Por ejemplo, en una tabla que contiene productos, se podría agregar una restricción de verificación tal que el precio de un producto y la cantidad de un producto sea un valor no negativo:

 PRICE >= 0
 QUANTITY >= 0

Si estas restricciones no estuvieran vigentes, sería posible tener un precio negativo (- $ 30) o una cantidad (−3 artículos).

Las restricciones de verificación se utilizan para garantizar la validez de los datos en una base de datos y para proporcionar integridad a los datos . Si se usan en el nivel de la base de datos, las aplicaciones que usan la base de datos no podrán agregar datos inválidos o modificar datos válidos, por lo que los datos se vuelven inválidos, incluso si la aplicación misma acepta datos inválidos.

Definición

Cada restricción de verificación debe definirse en la instrucción CREATE TABLE o ALTER TABLE utilizando la sintaxis:

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

Si la restricción de verificación se refiere a una sola columna solamente, es posible especificar la restricción como parte de la definición de la columna.

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

Restricción NOT NULL

Una restricción es funcionalmente equivalente a la siguiente restricción de verificación con un predicado: NOT NULLIS NOT NULL

 CHECK (column IS NOT NULL)

Algunos sistemas de administración de bases de datos relacionales pueden optimizar el rendimiento cuando NOT NULL se usa la CHECK sintaxis de restricción en oposición a la sintaxis de restricción dada anteriormente.

Restricciones comunes

La mayoría de los sistemas de administración de bases de datos restringen las restricciones de verificación a una sola fila, con acceso a constantes y funciones deterministas, pero no a datos en otras tablas, ni a datos invisibles para la transacción actual debido al aislamiento de la transacción .

Tales restricciones no son realmente restricciones de verificación de tabla, sino restricciones de verificación de fila . Debido a que estas restricciones generalmente solo se verifican cuando una fila se actualiza directamente (por razones de rendimiento) y, a menudo, se implementan implícitamente INSERT o como UPDATE disparadores, las restricciones de integridad podrían violarse mediante acciones indirectas si no fuera por estas limitaciones. Además, la CHECK restricción evitaría las modificaciones válidas de estos registros . Algunos ejemplos de restricciones peligrosas incluyen:

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

Se pueden utilizar activadores definidos por el usuario para evitar estas restricciones. Aunque es similar en implementación, está semánticamente claro que los disparadores solo se activarán cuando la tabla se modifique directamente, y que es responsabilidad del diseñador manejar cambios indirectos e importantes en otras tablas; las restricciones, por otro lado, están destinadas a ser "verdaderas en todo momento" independientemente de las acciones del usuario o de la falta de previsión del diseñador.

Referencias

  1. ^ Documentación de PostgreSQL 13, Capítulo 5. Definición de datos , Sección 5.4.2. Restricciones no nulas , sitio web: https://www.postgresql.org/docs/13/ddl-constraints.html , consultado el 9 de enero de 2021