Dans SQL Server, une contrainte de clé étrangère (et un CHECK contrainte) peut être de confiance ou non.
Lorsqu'une contrainte est approuvée, cela signifie que la contrainte a été vérifiée par le système. Lorsqu'elle n'est pas fiable, la contrainte n'a pas été vérifié par le système.
Fondamentalement, lorsque vous avez une contrainte non approuvée, vous pouvez également avoir des données non valides dans votre base de données. Je veux dire par là que vous pourriez avoir des données qui violent la contrainte.
Cela signifie que vous ne maintenez plus l'intégrité référentielle au sein de vos relations, ce qui n'est normalement pas une bonne pratique lorsque vous vous occupez d'une base de données relationnelle en production.
Dans cet article, je vérifierai mes contraintes existantes pour leur "fiabilité", puis je les mettrai à jour pour qu'elles redeviennent dignes de confiance.
Exemple 1 - Examiner les contraintes existantes
Vous pouvez savoir si une contrainte est approuvée ou non en interrogeant sys.foreign_keys vue système.
Comme ceci :
SELECT name AS 'Constraint', is_disabled, is_not_trusted FROM sys.foreign_keys;
Résultat :
+-------------------+---------------+------------------+ | Constraint | is_disabled | is_not_trusted | |-------------------+---------------+------------------| | FK_Albums_Artists | 1 | 1 | | FK_Albums_Genres | 0 | 1 | +-------------------+---------------+------------------+
OK, cela me dit que j'ai deux contraintes de clé étrangère et qu'elles ne sont pas fiables.
L'une des contraintes est désactivée, il est donc logique qu'elle ne soit pas fiable (de mauvaises données peuvent entrer dans la base de données chaque fois que la contrainte est désactivée).
Mais l'autre contrainte est activée, elle ne devrait donc pas être douteuse. Être non approuvé signifie qu'il pourrait y avoir des données non valides dans la base de données. Cela ne veut pas dire qu'il existe données invalides, juste qu'il pourrait être.
Fondamentalement, en étant activé, il vérifiera les données futures, mais il ne peut pas garantir les données existantes. Si une contrainte est approuvée, vous pouvez être sûr que toutes les données existantes sont valides.
Renvoyer uniquement les contraintes non approuvées
Vous préférerez peut-être utiliser un WHERE clause pour renvoyer uniquement les contraintes non approuvées. Comme ceci :
SELECT name AS 'Constraint', is_disabled, is_not_trusted FROM sys.foreign_keys WHERE is_not_trusted = 1;
Résultat :
+-------------------+---------------+------------------+ | Constraint | is_disabled | is_not_trusted | |-------------------+---------------+------------------| | FK_Albums_Artists | 1 | 1 | | FK_Albums_Genres | 0 | 1 | +-------------------+---------------+------------------+
Donc, dans ce cas, le résultat est le même (car toutes les contraintes actuelles ne sont pas fiables).
Exemple 2 – Restaurer la confiance
Pour restaurer la confiance à votre contrainte activée, réactivez-la simplement tout en utilisant le WITH CHECK option.
Comme ceci :
ALTER TABLE Albums WITH CHECK CHECK CONSTRAINT FK_Albums_Genres;
Maintenant, lorsque nous interrogeons sys.foreign_keys nous obtenons un résultat différent :
SELECT name AS 'Constraint', is_disabled, is_not_trusted FROM sys.foreign_keys;
Résultat :
+-------------------+---------------+------------------+ | Constraint | is_disabled | is_not_trusted | |-------------------+---------------+------------------| | FK_Albums_Artists | 1 | 1 | | FK_Albums_Genres | 0 | 0 | +-------------------+---------------+------------------+
Nous pouvons voir que la contrainte est maintenant approuvée, car le is_not_trusted l'indicateur est défini sur 0 .
Exemple 3 – Comment la contrainte est-elle devenue non fiable ?
Lorsque vous désactivez une contrainte de clé étrangère, elle devient automatiquement non fiable. Lorsque vous réactivez la même contrainte, vous avez la possibilité de restaurer sa confiance. Si vous ne le faites pas, il restera non fiable.
Lorsque vous activez une contrainte de clé étrangère, vous avez la possibilité de spécifier WITH CHECK ou WITH NOCHECK . Si vous spécifiez la dernière, votre contrainte restera non approuvée une fois qu'elle aura été activée.
Il est important de noter que WITH NOCHECK est l'option par défaut, donc si vous ne spécifiez pas explicitement qu'elle doit être approuvée, la contrainte sera activée comme non approuvée.
Cependant, c'est le contraire lorsque vous créez une contrainte de clé étrangère. Lorsque vous créez la contrainte pour la première fois, l'option par défaut est WITH CHECK . Donc, si vous omettez ce paramètre, il sera approuvé par défaut (sauf si vous avez des données invalides, auquel cas il ne sera pas activé). Cependant, vous pouvez remplacer ce paramètre en spécifiant explicitement WITH NOCHECK lorsque vous créez la contrainte.
Pour montrer comment vos contraintes activées peuvent facilement rester non fiables, je vais réactiver l'autre clé (celle désactivée), mais j'utiliserai le paramètre par défaut :
ALTER TABLE Albums CHECK CONSTRAINT FK_Albums_Artists; SELECT name AS 'Constraint', is_disabled, is_not_trusted FROM sys.foreign_keys;
Résultat :
+-------------------+---------------+------------------+ | Constraint | is_disabled | is_not_trusted | |-------------------+---------------+------------------| | FK_Albums_Artists | 0 | 1 | | FK_Albums_Genres | 0 | 0 | +-------------------+---------------+------------------+
Donc, en étant paresseux (ou oublieux) et en ne spécifiant pas explicitement WITH CHECK , j'ai réussi à activer une contrainte tout en gardant intact son statut "non approuvé".
La clé à retenir est la suivante :si vous souhaitez que vos contraintes réactivées soient fiables, vous devez toujours les activer en utilisant WITH CHECK .
