Cómo habilitar todas las restricciones de CHECK y clave externa para una tabla en SQL Server (ejemplos de T-SQL)

Puede usar el siguiente código para habilitar todos los CHECK y restricciones de clave externa para una tabla específica en SQL Server.

Cuando habilita una restricción en SQL Server, debe decidir si debe verificar los datos existentes o no. Esta es una consideración importante si la tabla ya contiene datos, porque los datos existentes pueden potencialmente violar las reglas de la restricción.

Ejemplos de declaraciones

A continuación, se incluyen dos declaraciones de muestra que muestran la diferencia entre verificar los datos existentes y no verificarlos cuando habilita las restricciones.

Para comprobar los datos existentes, utilice WITH CHECK en su declaración al habilitar las restricciones, de lo contrario use WITH NOCHECK .

Con Cheque:

ALTER TABLE TableName 
WITH CHECK 
CHECK CONSTRAINT ALL

Sin verificación:

ALTER TABLE TableName 
WITH NOCHECK 
CHECK CONSTRAINT ALL

Simplemente reemplace TableName con el nombre de la tabla aplicable.

A continuación se muestra un ejemplo en el que hago esto y verifico los resultados.

Ejemplo 1:revisar las restricciones

Primero, echaré un vistazo rápido al CHECK actual restricciones en la base de datos, para ver si están habilitadas o deshabilitadas.

SELECT
  OBJECT_NAME(parent_object_id) AS 'Table',
  name AS 'Constraint',
  is_disabled, 
  is_not_trusted
FROM sys.foreign_keys
UNION
SELECT 
  OBJECT_NAME(parent_object_id),
  name,
  is_disabled, 
  is_not_trusted
FROM sys.check_constraints;

Resultado:

+----------------+-----------------+---------------+------------------+
| Table          | Constraint      | is_disabled   | is_not_trusted   |
|----------------+-----------------+---------------+------------------|
| ConstraintTest | chkPrice        | 1             | 1                |
| ConstraintTest | chkValidEndDate | 1             | 1                |
| ConstraintTest | chkTeamSize     | 1             | 1                |
| Occupation     | chkJobTitle     | 0             | 0                |
+----------------+-----------------+---------------+------------------+

Así que actualmente hay cuatro CHECK restricciones en la base de datos, tres de las cuales son para ConstraintTest mesa.

Podemos ver que todas las restricciones de la tabla están deshabilitadas porque is_disabled está establecido en 1 .

También podemos ver que is_not_trusted la columna se establece en 1 para estas restricciones. Esto significa que no son de confianza. No se puede confiar en ellos mientras están deshabilitados, porque los datos no válidos pueden ingresar a la base de datos sin ser verificados. Más sobre esto a continuación.

La otra restricción (para otra tabla) ya está habilitada y es de confianza (pero podemos ignorar esa tabla/restricción en este artículo).

Ejemplo 2:habilite las restricciones con WITH CHECK

Ahora habilitaré todas las restricciones para ConstraintTest tabla:

ALTER TABLE ConstraintTest 
WITH CHECK CHECK CONSTRAINT ALL;

Eso es todo, hecho.

Ahora ejecutemos la misma consulta del primer ejemplo para ver el resultado.

SELECT
  OBJECT_NAME(parent_object_id) AS 'Table',
  name AS 'Constraint',
  is_disabled, 
  is_not_trusted
FROM sys.foreign_keys
UNION
SELECT 
  OBJECT_NAME(parent_object_id),
  name,
  is_disabled, 
  is_not_trusted
FROM sys.check_constraints;

Resultado:

+----------------+-----------------+---------------+------------------+
| Table          | Constraint      | is_disabled   | is_not_trusted   |
|----------------+-----------------+---------------+------------------|
| ConstraintTest | chkPrice        | 0             | 0                |
| ConstraintTest | chkValidEndDate | 0             | 0                |
| ConstraintTest | chkTeamSize     | 0             | 0                |
| Occupation     | chkJobTitle     | 0             | 0                |
+----------------+-----------------+---------------+------------------+

Las tres restricciones para ConstraintTest ahora están habilitadas y son de confianza.

Son de confianza porque usé WITH CHECK en mi declaración. Si no lo hubiera hecho, habría obtenido un resultado diferente, como verá a continuación.

Usando WITH CHECK , puedo estar seguro de que todos los datos existentes en la tabla se ajustan a las restricciones.

Ejemplo 3:habilite las restricciones usando WITH NOCHECK

Ahora volveré a habilitar las restricciones usando WITH CHECK para que podamos ver cómo esto afecta el resultado.

Pero primero tendré que deshabilitarlos:

ALTER TABLE ConstraintTest 
NOCHECK CONSTRAINT ALL;

Comprueba que estén deshabilitados:

SELECT
  OBJECT_NAME(parent_object_id) AS 'Table',
  name AS 'Constraint',
  is_disabled, 
  is_not_trusted
FROM sys.foreign_keys
UNION
SELECT 
  OBJECT_NAME(parent_object_id),
  name,
  is_disabled, 
  is_not_trusted
FROM sys.check_constraints;

Resultado:

+----------------+-----------------+---------------+------------------+
| Table          | Constraint      | is_disabled   | is_not_trusted   |
|----------------+-----------------+---------------+------------------|
| ConstraintTest | chkPrice        | 1             | 1                |
| ConstraintTest | chkValidEndDate | 1             | 1                |
| ConstraintTest | chkTeamSize     | 1             | 1                |
| Occupation     | chkJobTitle     | 0             | 0                |
+----------------+-----------------+---------------+------------------+

Así que están deshabilitados una vez más.

Ahora vuelva a habilitarlos usando WITH NOCHECK :

ALTER TABLE ConstraintTest 
WITH NOCHECK CHECK CONSTRAINT ALL;

Vuelva a comprobar:

SELECT
  OBJECT_NAME(parent_object_id) AS 'Table',
  name AS 'Constraint',
  is_disabled, 
  is_not_trusted
FROM sys.foreign_keys
UNION
SELECT 
  OBJECT_NAME(parent_object_id),
  name,
  is_disabled, 
  is_not_trusted
FROM sys.check_constraints;

Resultado:

+----------------+-----------------+---------------+------------------+
| Table          | Constraint      | is_disabled   | is_not_trusted   |
|----------------+-----------------+---------------+------------------|
| ConstraintTest | chkPrice        | 0             | 1                |
| ConstraintTest | chkValidEndDate | 0             | 1                |
| ConstraintTest | chkTeamSize     | 0             | 1                |
| Occupation     | chkJobTitle     | 0             | 0                |
+----------------+-----------------+---------------+------------------+

Podemos ver que las restricciones se han habilitado con éxito, pero esta vez siguen sin ser de confianza.

Las restricciones no son de confianza porque no verificaron ningún dato existente antes de habilitarse.

Entonces, la conclusión clave aquí es que, si desea que se confíe en sus restricciones, asegúrese de usar WITH CHECK al habilitarlos.

Habilitación de restricciones individualmente

Si no desea habilitar todas las restricciones a la vez, puede habilitarlas individualmente. Esto también puede ser útil si necesita habilitar todas las restricciones, pero necesita usar configuraciones diferentes (por ejemplo, WITH CHECK para algunos y WITH NOCHECK para otros).

Consulte Cómo habilitar una restricción CHECK en SQL Server y Cómo habilitar una clave externa en SQL Server.