Application des contraintes de clé étrangère

la vérification des contraintes de clé étrangère.
Tout d’abord, si l’on souhaite ajouter des contraintes après avoir inséré des données, il ne faut pas définir ses contraintes dans l’instruction CREATE TABLE. Après avoir inséré les données initiales, on peut ajouter des contraintes en utilisant la commande ALTER TABLE. Lorsque l’on utilise ALTER TABLE pour ajouter une nouvelle contrainte de clé étrangère portant sur une table contenant déjà  des données, par défaut, SQL Server contrôle les données existantes pour valider les contraintes. S’il y a des violations de contrainte, la base de données ne rajoute pas la contrainte. Avec des tables de grande taille, une telle vérification peut prendre un certain temps.
Il existe néanmoins une alternative : on peut ajouter une contrainte de clé étrangère et omettre la vérification en sélectionnant l’option WITH NOCHECK dans l’instruction ALTER TABLE. Ainsi, SQL Server vérifiera toutes les opérations suivantes, mais ne vérifiera pas les données existantes. Ce procédé est parfois appelé report d’une contrainte. Voici un exemple d’ajout de contrainte de clé étrangère à  une table existante (remarquez la clause WITH NOCHECK).

ALTER TABLE table2
WITH NOCHECK
ADD CONSTRAINT FK_Table2_Table1_a FOREIGN KEY(a)
REFERENCES Table1(a)

Avec la seconde possibilité, le propriétaire de la table peut désactiver temporairement la vérification des références de clé étrangère en utilisant l’instruction suivante :

ALTER TABLE table_name NOCHECK CONSTRAINT
constraint_name

On peut rétablir la contrainte clé étrangère en utilisant l’instruction suivante :

ALTER TABLE table_name CHECK CONSTRAINT constraint_name

Notez que lorsqu’on utilise cette méthode pour réactiver une contrainte existante, SQL Server ne vérifie pas automatiquement que tous les enregistrements respectent cette contrainte. Pour vérifier les enregistrements existants, il suffit de lancer une mise à  jour factice en remplaçant les valeurs d’une colonne par les mêmes valeurs existantes, et ce, pour tous les enregistrements (par exemple, UPDATE ORDERS SET cust_id = cust_id) et, si des violations de contrainte se produisent, vous pouvez les résoudre.
Les deux possibilités décrites précédemment sont identiques dans leur syntaxe et peuvent prêter à  confusion. La différence principale entre les deux se trouve dans l’utilisation du terme WITH. Pour reporter une contrainte, on doit modifier (ALTER) la table sans vérification (WITH NOCHECK). Pour désactiver une contrainte, on doit modifier (ALTER) la table et spécifiez NOCHECK, suivi du nom de la contrainte.
Pour terminer, on peut utiliser bcp ou la commande BULK INSERT pour charger les données initiales. Par défaut, la commande BULK INSERT et le programme bcp ne vérifient aucune contrainte de clé étrangère. On peut utiliser l’option CHECK_CONSTRAINTS pour modifier ce comportement. La commande BULK INSERT et le programme bcp sont plus rapides que les commandes INSERT classiques, car ils contournent généralement les contrôles d’intégrité habituels, ainsi que la plupart des actions de journalisation. Si on opte pour l’exécution du programme bcp ou de la commande BULK INSERT sans vérification de contraintes, on peut réaliser une mise à  jour factice pour signaler la présence de violations dans les données existantes, comme je l’ai décrit dans l’exemple de réactivation d’une contrainte. Dans le cas contraire, les utilisateurs peuvent recevoir des messages d’erreur de contrainte lors de l’exécution d’opérations de mise à  jour sur des données préexistantes, même si aucune valeur n’a été modifiée.
La possibilité de définir une action référentielle CASCADE a été l’une des demandes de fonctionnalités les plus courantes enregistrées par l’équipe de développement de SQL Server 2000. Les autres systèmes de base de données, Microsoft Access y compris, comportent cette fonctionnalité. Mais examinez scrupuleusement la conception de votre application avant d’ajouter des actions CASCADE à  vos tables, ou même avant de définir des contraintes de clé étrangère. Vous trouverez peut-être que l’utilisation d’un algorithme dans l’application pour la mise en oeuvre d’actions référentielles autres que NO ACTION est souvent plus appropriée. Bien que les actions référentielles puissent être intuitives, demandez-vous combien d’applications pourraient bénéficier de cette fonction ? Combien d’exemples effectifs impliquent une application si simpliste que l’on pourrait supprimer sans condition (ou mettre à  la valeur par défaut ou à  NULL) tous les enregistrements correspondants d’une table associée ? La plupart des applications font des contrôles supplémentaires. Elles peuvent par exemple demander à  l’utilisateur s’il souhaite réellement supprimer un client ayant des commandes en cours. La nature déclarative des actions référentielles ne fournit aucun moyen de définir un algorithme dans l’application permettant de traiter des cas comme ceux-là . L’action la plus pratique consiste probablement à  utiliser les contraintes de clé étrangère de SQL Server pour garantir qu’aucun enregistrement ne viole les relations, et s’assurer que toutes les applications traitent les actions en CASCADE et autres actions référentielles spéciales de manière individuelle.

Kalen Delaney est formatrice et consultante indépendante sur SQL Server, MCT et MCSE. Elle est l’auteur de l’ouvrage Inside SQL Server 7.0 (Microsoft Press).