Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

Comment activer toutes les contraintes de vérification et de clé étrangère pour une table dans SQL Server (exemples T-SQL)

Vous pouvez utiliser le code ci-dessous pour activer tous les CHECK et les contraintes de clé étrangère pour une table spécifique dans SQL Server.

Lorsque vous activez une contrainte dans SQL Server, vous devez décider si elle doit vérifier ou non les données existantes. Il s'agit d'une considération importante si la table contient déjà des données, car ces données existantes peuvent potentiellement enfreindre les règles de la contrainte.

Exemples de déclarations

Vous trouverez ci-dessous deux exemples d'instructions qui montrent la différence entre vérifier les données existantes et ne pas les vérifier lorsque vous activez les contraintes.

Pour vérifier les données existantes, utilisez WITH CHECK dans votre déclaration lors de l'activation des contraintes, sinon utilisez WITH NOCHECK .

Avec Chèque :

ALTER TABLE TableName 
WITH CHECK 
CHECK CONSTRAINT ALL

Sans chèque :

ALTER TABLE TableName 
WITH NOCHECK 
CHECK CONSTRAINT ALL

Remplacez simplement TableName avec le nom de la table applicable.

Voici un exemple où je fais cela et vérifie les résultats.

Exemple 1 - Examiner les contraintes

Tout d'abord, je vais jeter un coup d'œil au CHECK actuel contraintes dans la base de données, pour voir si oui ou non elles sont activées ou désactivées.

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;

Résultat :

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

Il y a donc actuellement quatre CHECK contraintes dans la base de données, dont trois pour le ConstraintTest tableau.

Nous pouvons voir que toutes les contraintes de la table sont désactivées car is_disabled est défini sur 1 .

Nous pouvons également voir que le is_not_trusted la colonne est définie sur 1 pour ces contraintes. Cela signifie qu'ils ne sont pas dignes de confiance. On ne peut pas leur faire confiance tant qu'ils sont désactivés, car des données non valides peuvent entrer dans la base de données sans être vérifiées. Plus d'informations ci-dessous.

L'autre contrainte (pour une autre table) est déjà activée et approuvée (mais nous pouvons ignorer cette table/contrainte dans cet article).

Exemple 2 - Activer les contraintes à l'aide de WITH CHECK

Maintenant, je vais activer toutes les contraintes pour le ConstraintTest tableau :

ALTER TABLE ConstraintTest 
WITH CHECK CHECK CONSTRAINT ALL;

Voilà, c'est fait.

Exécutons maintenant la même requête du premier exemple pour voir le résultat.

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;

Résultat :

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

Les trois contraintes pour le ConstraintTest table sont maintenant activés et approuvés.

Ils sont dignes de confiance car j'ai utilisé WITH CHECK dans ma déclaration. Si je ne l'avais pas fait, j'aurais obtenu un résultat différent, comme vous le verrez ci-dessous.

En utilisant WITH CHECK , je peux être sûr que toutes les données existantes dans la table sont en fait conformes aux contraintes.

Exemple 3 - Activer les contraintes à l'aide de WITH NOCHECK

Maintenant, je vais réactiver les contraintes en utilisant WITH CHECK afin que nous puissions voir comment cela affecte le résultat.

Mais je dois d'abord les désactiver :

ALTER TABLE ConstraintTest 
NOCHECK CONSTRAINT ALL;

Vérifiez qu'ils sont désactivés :

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;

Résultat :

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

Ils sont donc à nouveau désactivés.

Maintenant, réactivez-les en utilisant WITH NOCHECK :

ALTER TABLE ConstraintTest 
WITH NOCHECK CHECK CONSTRAINT ALL;

Vérifiez à nouveau :

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;

Résultat :

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

Nous pouvons voir que les contraintes ont été activées avec succès, mais cette fois, elles restent non fiables.

Les contraintes ne sont pas fiables car elles n'ont vérifié aucune donnée existante avant d'être activées.

Donc, la clé à retenir ici est que si vous voulez que vos contraintes soient fiables, assurez-vous d'utiliser WITH CHECK lors de leur activation.

Activer les contraintes individuellement

Si vous ne souhaitez pas activer toutes les contraintes à la fois, vous pouvez les activer individuellement. Cela peut également être utile si vous devez activer toutes les contraintes, mais que vous devez utiliser des paramètres différents (par exemple, WITH CHECK pour certains et WITH NOCHECK pour les autres).

Voir Comment activer une contrainte CHECK dans SQL Server et Comment activer une clé étrangère dans SQL Server.