Como habilitar todas as restrições CHECK e de chave estrangeira para uma tabela no SQL Server (Exemplos de T-SQL)

Você pode usar o código abaixo para habilitar todos os CHECK e restrições de chave estrangeira para uma tabela específica no SQL Server.

Ao habilitar uma restrição no SQL Server, você precisa decidir se ela deve verificar algum dado existente ou não. Essa é uma consideração importante se a tabela já contiver dados, pois esses dados existentes podem potencialmente violar as regras da restrição.

Exemplos de extratos

Abaixo estão duas instruções de exemplo que mostram a diferença entre verificar os dados existentes e não verificá-los quando você habilita as restrições.

Para verificar os dados existentes, use WITH CHECK em sua instrução ao habilitar as restrições, caso contrário, use WITH NOCHECK .

Com cheque:

ALTER TABLE TableName 
WITH CHECK 
CHECK CONSTRAINT ALL

Sem verificação:

ALTER TABLE TableName 
WITH NOCHECK 
CHECK CONSTRAINT ALL

Basta substituir TableName com o nome da tabela aplicável.

Abaixo está um exemplo onde eu faço isso e verifico os resultados.

Exemplo 1 – Revise as restrições

Primeiro, darei uma olhada rápida no CHECK atual restrições no banco de dados, para ver se estão ou não habilitadas ou desabilitadas.

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                |
+----------------+-----------------+---------------+------------------+

Portanto, existem atualmente quatro CHECK restrições no banco de dados, três das quais são para o ConstraintTest tabela.

Podemos ver que todas as restrições da tabela estão desabilitadas porque is_disabled está definido como 1 .

Também podemos ver que o is_not_trusted coluna está definida como 1 para essas restrições. Isso significa que eles não são confiáveis. Eles não podem ser confiáveis enquanto estão desabilitados, porque dados inválidos podem entrar no banco de dados sem serem verificados. Mais sobre isso abaixo.

A outra restrição (para outra tabela) já está habilitada e confiável (mas podemos ignorar essa tabela/restrição neste artigo).

Exemplo 2 – Habilite as Restrições usando WITH CHECK

Agora vou habilitar todas as restrições para o ConstraintTest tabela:

ALTER TABLE ConstraintTest 
WITH CHECK CHECK CONSTRAINT ALL;

É isso – feito.

Agora vamos executar a mesma consulta do primeiro exemplo para ver o 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                |
+----------------+-----------------+---------------+------------------+

Todas as três restrições para o ConstraintTest table agora estão habilitados e confiáveis.

Eles são confiáveis porque eu usei WITH CHECK na minha declaração. Se não tivesse, teria obtido um resultado diferente, como você verá abaixo.

Usando WITH CHECK , posso ter certeza de que quaisquer dados existentes na tabela estão de fato em conformidade com as restrições.

Exemplo 3 – Habilite as Restrições usando WITH NOCHECK

Agora vou reativar as restrições usando WITH CHECK para que possamos ver como isso afeta o resultado.

Mas primeiro vou precisar desativá-los:

ALTER TABLE ConstraintTest 
NOCHECK CONSTRAINT ALL;

Verifique se eles estão desativados:

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                |
+----------------+-----------------+---------------+------------------+

Então eles estão desativados mais uma vez.

Agora reative-os usando WITH NOCHECK :

ALTER TABLE ConstraintTest 
WITH NOCHECK CHECK CONSTRAINT ALL;

Verifique novamente:

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 as restrições foram habilitadas com sucesso, mas desta vez elas permanecem não confiáveis.

As restrições não são confiáveis porque não verificaram nenhum dado existente antes de serem habilitadas.

Portanto, o principal argumento aqui é que, se você deseja que suas restrições sejam confiáveis, use WITH CHECK ao habilitá-los.

Ativando restrições individualmente

Se você não quiser habilitar todas as restrições de uma vez, poderá habilitá-las individualmente. Isso também pode ser útil se você precisar habilitar todas as restrições, mas precisar usar configurações diferentes (por exemplo, WITH CHECK para alguns e WITH NOCHECK para os outros).

Consulte Como habilitar uma restrição CHECK no SQL Server e como habilitar uma chave estrangeira no SQL Server.