Wenn Sie eine Fremdschlüsseleinschränkung in SQL Server haben, die derzeit deaktiviert ist, können Sie den folgenden Code verwenden, um sie wieder zu aktivieren.
Wenn Sie eine Fremdschlüsseleinschränkung aktivieren, haben Sie die Möglichkeit anzugeben, ob vorhandene Daten in der Tabelle überprüft werden sollen oder nicht. Dies gilt auch, wenn Sie einen CHECK aktivieren Einschränkung.
Nachfolgend finden Sie Codebeispiele zum Aktivieren einer Fremdschlüsselbeschränkung, während Sie jede dieser verschiedenen Optionen angeben.
Beispiel 1 – Aktivieren Sie eine Einschränkung mit WITH CHECK
Dies ist die empfohlene Methode (es sei denn, Sie haben einen bestimmten Grund, sie nicht zu verwenden).
Hier ist ein Beispiel für die Aktivierung einer Fremdschlüsselbeschränkung namens FK_Albums_Artists :
ALTER TABLE Albums WITH CHECK CHECK CONSTRAINT FK_Albums_Artists;
Hier gebe ich ausdrücklich WITH CHECK an , die SQL Server anweist, die vorhandenen Daten zu überprüfen, bevor die Einschränkung aktiviert wird. Wenn Daten gegen die Einschränkung verstoßen, wird die Einschränkung nicht aktiviert und Sie erhalten eine Fehlermeldung.
Das ist gut, weil es die referentielle Integrität erzwingt.
Wenn Sie eine neue Fremdschlüsseleinschränkung erstellen, ist dies die Standardeinstellung. Wenn Sie jedoch eine vorhandene Einschränkung aktivieren (wie wir es hier tun), ist dies nicht der Fall die Standardeinstellung.
Beispiel 2 – Aktivieren Sie eine Einschränkung mit WITH NOCHECK
In diesem Beispiel wird die Einschränkung aktiviert, ohne die vorhandenen Daten zu prüfen:
ALTER TABLE Albums WITH NOCHECK CHECK CONSTRAINT FK_Albums_Artists;
Hier gebe ich ausdrücklich WITH NOCHECK an , die SQL Server anweist, die vorhandenen Daten nicht zu überprüfen. Das bedeutet, dass die Einschränkung auch dann aktiviert wird, wenn die Tabelle bereits Daten enthält, die gegen die Einschränkung verstoßen.
Dies ist die Standardeinstellung beim Aktivieren einer Einschränkung (aber nicht beim Erstellen).
Einer der wenigen Gründe (wahrscheinlich der einzige Grund), warum Sie dies verwenden würden, ist, wenn Sie ungültige Daten in der Datenbank behalten möchten. Möglicherweise haben Sie eine einmalige Ausnahme, bei der Sie eine oder mehrere Zeilen mit ungültigen Daten eingeben müssen, aber alle zukünftigen Daten der Einschränkung entsprechen müssen.
Allerdings sind damit immer noch Risiken verbunden. Hier ist, was Microsoft dazu zu sagen hat:
Wir empfehlen dies nicht, außer in seltenen Fällen. Die neue Einschränkung wird in allen späteren Datenaktualisierungen ausgewertet. Alle Beschränkungsverletzungen, die durch WITH NOCHECK unterdrückt werden Wenn die Einschränkung hinzugefügt wird, können zukünftige Aktualisierungen fehlschlagen, wenn sie Zeilen mit Daten aktualisieren, die der Einschränkung nicht folgen.
Verwenden Sie also WITH NOCHECK könnte später möglicherweise Probleme verursachen.
Beispiel 3 – Aktivieren Sie eine Einschränkung mit der Standardoption
Hier ist ein Beispiel mit der Standardoption:
ALTER TABLE Albums CHECK CONSTRAINT FK_Albums_Artists;
Dieses Beispiel entspricht dem vorherigen Beispiel. Da ich nicht angegeben habe, ob geprüft werden soll oder nicht, geht SQL Server davon aus, dass ich WITH NOCHECK möchte .
Achten Sie also darauf, ausdrücklich WITH CHECK anzugeben wenn Sie Probleme mit der referenziellen Integrität vermeiden möchten.
Die Verwendung von WITH NOCHECK entfernt das Vertrauen
Wenn Sie eine Einschränkung mit (dem Standard) WITH NOCHECK aktivieren , ist eine Konsequenz, der Sie sich bewusst sein sollten, dass SQL Server dieser Einschränkung nicht mehr vertraut. Es kennzeichnet es als nicht vertrauenswürdig. Tatsächlich wird es bereits als nicht vertrauenswürdig gekennzeichnet, wenn Sie die Einschränkung deaktivieren.
SQL Server hat einen is_not_trusted Flag, das es auf 1 setzt wenn Sie eine Fremdschlüsselbeschränkung deaktivieren (was bedeutet, dass sie nicht vertrauenswürdig ist), und die einzige Möglichkeit, sie auf 0 zu setzen (vertrauenswürdig) ist WITH CHECK anzugeben beim erneuten Aktivieren der Einschränkung. Andererseits mit WITH NOCHECK aktiviert es einfach, ohne vorhandene Daten zu prüfen.
Durch die Verwendung von WITH CHECK stellen Sie sicher, dass die Einschränkung alle vorhandenen Daten überprüft, bevor sie aktiviert wird. Sie kann nur aktiviert werden, wenn alle vorhandenen Daten der Einschränkung entsprechen. Sobald alle vorhandenen Daten überprüft wurden, kann der Einschränkung vertraut werden.
Beispiel 4 – Überprüfen Sie den Status „Vertrauenswürdig/Deaktiviert“
Sie können den vertrauenswürdigen und deaktivierten Status überprüfen, indem Sie sys.foreign_keys abfragen Systemansicht.
So:
SELECT name AS 'Constraint', is_disabled, is_not_trusted FROM sys.foreign_keys;
Ergebnis:
+-------------------+---------------+------------------+ | Constraint | is_disabled | is_not_trusted | |-------------------+---------------+------------------| | FK_Albums_Artists | 0 | 1 | | FK_Albums_Genres | 0 | 0 | +-------------------+---------------+------------------+
Das sagt mir, dass die Einschränkung, die ich im vorherigen Beispiel aktiviert habe ( FK_Albums_Artists ) ist nicht vertrauenswürdig.
Dies liegt daran, dass ich es mit der Standardeinstellung aktiviert habe, die WITH NOCHECK ist .
Wenn ich es mit WITH CHECK wieder aktiviere , Folgendes passiert:
ALTER TABLE Albums WITH CHECK CHECK CONSTRAINT FK_Albums_Artists; SELECT name AS 'Constraint', is_disabled, is_not_trusted FROM sys.foreign_keys;
Ergebnis:
+-------------------+---------------+------------------+ | Constraint | is_disabled | is_not_trusted | |-------------------+---------------+------------------| | FK_Albums_Artists | 0 | 0 | | FK_Albums_Genres | 0 | 0 | +-------------------+---------------+------------------+
Glücklicherweise hatte ich in diesem Fall keine Daten, die gegen die Einschränkung verstießen, sodass die Einschränkung erfolgreich aktiviert und ihr Vertrauen wiederhergestellt wurde.
Wenn es Daten gab, die gegen die Einschränkung verstießen, wurde ein Fehler angezeigt und ich musste die Daten korrigieren, bevor ich das Vertrauen in die Einschränkung wiederherstellen konnte.
