Una restricción de comprobación es un tipo de restricción de integridad en SQL que especifica un requisito que debe cumplir cada fila de 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 como UNKNOWN, entonces no se viola la restricción y la fila se puede insertar o actualizar en la tabla. Esto es contrario a los predicados en WHEREcláusulas en declaraciones SELECTo .UPDATE
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:
precio >= 0
cantidad >= 0
Si no existieran estas restricciones, sería posible tener un precio negativo (−$30) o una cantidad negativa (−3 artículos).
Las restricciones de comprobación se utilizan para garantizar la validez de los datos en una base de datos y para proporcionar integridad a los datos . Si se utilizan a nivel de la base de datos, las aplicaciones que utilizan la base de datos no podrán agregar datos no válidos ni modificar datos válidos, por lo que los datos se vuelven no válidos, incluso si la propia aplicación acepta datos no válidos.
Cada restricción de verificación debe definirse en la declaración CREATE TABLEor ALTER TABLEutilizando la sintaxis:
CREAR TABLA nombre_tabla ( ..., RESTRICCIÓN nombre_restricción CHECK ( predicado ), ...)
ALTER TABLE nombre_tabla ADD CONSTRAINT nombre_restricción CHECK ( predicado )
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.
CREAR TABLA nombre_tabla ( ... nombre_columna tipo CHECK ( predicado ), ...)
Una restricción es funcionalmente equivalente a la siguiente restricción de verificación con un predicado:NOT NULLIS NOT NULL
COMPROBAR ( la columna NO ES NULA)
Algunos sistemas de gestión de bases de datos relacionales pueden optimizar el rendimiento cuando NOT NULLse utiliza la sintaxis de restricción en lugar de la CHECKsintaxis de restricción indicada anteriormente. [1]
La mayoría de los sistemas de gestió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 de otras tablas, o a datos invisibles para la transacción actual debido al aislamiento de la transacción .
Estas restricciones no son realmente restricciones de verificación de tabla , sino más bien restricciones de verificación de fila . Debido a que estas restricciones generalmente solo se verifican cuando se actualiza directamente una fila (por razones de rendimiento) y a menudo se implementan como implícitas INSERTo UPDATEcomo activadores, las restricciones de integridad podrían ser violadas por una acción indirecta si no fuera por estas limitaciones. Además, la restricción impediría modificaciones válidas de estos registros CHECK. 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 su implementación es similar, resulta semánticamente claro que los activadores solo se activarán cuando se modifique directamente la tabla y que es responsabilidad del diseñador gestionar los cambios indirectos e importantes en otras tablas; por otro lado, las restricciones están pensadas para ser "verdaderas en todo momento", independientemente de las acciones del usuario o de la falta de previsión del diseñador.