In SQL Server ist eine Fremdschlüsseleinschränkung (und ein CHECK Constraint) kann entweder vertrauenswürdig oder nicht vertrauenswürdig sein.
Wenn einer Einschränkung vertraut wird, bedeutet dies, dass die Einschränkung vom System verifiziert wurde. Wenn ihr nicht vertraut wird, hat die Einschränkung nicht wurde vom System verifiziert.
Wenn Sie eine nicht vertrauenswürdige Einschränkung haben, könnten Sie grundsätzlich auch ungültige Daten in Ihrer Datenbank haben. Damit meine ich, dass Sie Daten haben könnten, die gegen die Einschränkung verstoßen.
Das bedeutet, dass Sie die referenzielle Integrität innerhalb Ihrer Beziehungen nicht mehr aufrechterhalten, was normalerweise keine gute Praxis ist, wenn Sie sich um eine relationale Datenbank in der Produktion kümmern.
In diesem Artikel überprüfe ich meine bestehenden Einschränkungen auf ihre „Vertrauenswürdigkeit“ und aktualisiere sie dann, um wieder vertrauenswürdig zu werden.
Beispiel 1 – Bestehende Beschränkungen überprüfen
Sie können herausfinden, ob eine Einschränkung vertrauenswürdig ist oder nicht, 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 | 1 | 1 | | FK_Albums_Genres | 0 | 1 | +-------------------+---------------+------------------+
OK, das sagt mir also, dass ich zwei Fremdschlüsseleinschränkungen habe und beide nicht vertrauenswürdig sind.
Eine der Einschränkungen ist deaktiviert, daher ist es sinnvoll, dass ihr nicht vertraut wird (ungültige Daten können in die Datenbank gelangen, wenn die Einschränkung deaktiviert ist).
Aber die andere Einschränkung ist aktiviert, also sollte ihr wirklich nicht nicht vertraut werden. Nicht vertrauenswürdig zu sein bedeutet, dass die Datenbank möglicherweise ungültige Daten enthält. Das bedeutet nicht, dass es gibt ungültige Daten, nur das könnte sein.
Grundsätzlich werden durch die Aktivierung zukünftige Daten überprüft, aber es kann nicht für vorhandene Daten bürgen. Wenn einer Einschränkung vertraut wird, können Sie sicher sein, dass alle vorhandenen Daten gültig sind.
Nur nicht vertrauenswürdige Einschränkungen zurückgeben
Möglicherweise bevorzugen Sie die Verwendung eines WHERE -Klausel, um nur die nicht vertrauenswürdigen Einschränkungen zurückzugeben. So:
SELECT name AS 'Constraint', is_disabled, is_not_trusted FROM sys.foreign_keys WHERE is_not_trusted = 1;
Ergebnis:
+-------------------+---------------+------------------+ | Constraint | is_disabled | is_not_trusted | |-------------------+---------------+------------------| | FK_Albums_Artists | 1 | 1 | | FK_Albums_Genres | 0 | 1 | +-------------------+---------------+------------------+
In diesem Fall ist das Ergebnis also dasselbe (weil alle aktuellen Einschränkungen nicht vertrauenswürdig sind).
Beispiel 2 – Vertrauen wiederherstellen
Um das Vertrauen in Ihre aktivierte Einschränkung wiederherzustellen, aktivieren Sie sie einfach erneut, während Sie WITH CHECK verwenden Option.
So:
ALTER TABLE Albums WITH CHECK CHECK CONSTRAINT FK_Albums_Genres;
Wenn wir jetzt sys.foreign_keys abfragen wir erhalten ein anderes Ergebnis:
SELECT name AS 'Constraint', is_disabled, is_not_trusted FROM sys.foreign_keys;
Ergebnis:
+-------------------+---------------+------------------+ | Constraint | is_disabled | is_not_trusted | |-------------------+---------------+------------------| | FK_Albums_Artists | 1 | 1 | | FK_Albums_Genres | 0 | 0 | +-------------------+---------------+------------------+
Wir können sehen, dass die Einschränkung jetzt vertrauenswürdig ist, weil is_not_trusted Flag ist auf 0 gesetzt .
Beispiel 3 – Wie wurde die Einschränkung nicht vertrauenswürdig?
Wenn Sie eine Fremdschlüsseleinschränkung deaktivieren, wird sie automatisch nicht vertrauenswürdig. Wenn Sie dieselbe Einschränkung erneut aktivieren, haben Sie die Möglichkeit, ihr Vertrauen wiederherzustellen. Wenn Sie dies nicht tun, bleibt es nicht vertrauenswürdig.
Wenn Sie eine Fremdschlüsseleinschränkung aktivieren, haben Sie die Möglichkeit, WITH CHECK anzugeben oder WITH NOCHECK . Wenn Sie Letzteres angeben, bleibt Ihre Einschränkung nicht vertrauenswürdig, sobald sie aktiviert wurde.
Es ist wichtig zu beachten, dass WITH NOCHECK ist die Standardoption. Wenn Sie also nicht ausdrücklich angeben, dass sie vertrauenswürdig sein soll, wird die Einschränkung als nicht vertrauenswürdig aktiviert.
Das Gegenteil ist jedoch der Fall, wenn Sie eine Fremdschlüsseleinschränkung erstellen. Wenn Sie die Einschränkung zum ersten Mal erstellen, ist die Standardoption WITH CHECK . Wenn Sie diese Einstellung also weglassen, wird ihr standardmäßig vertraut (es sei denn, Sie haben ungültige Daten, in diesem Fall wird sie nicht aktiviert). Sie können diese Einstellung jedoch überschreiben, indem Sie explizit WITH NOCHECK angeben wenn Sie die Einschränkung erstellen.
Um zu demonstrieren, wie Ihre aktivierten Einschränkungen leicht nicht vertrauenswürdig bleiben können, werde ich den anderen Schlüssel (den deaktivierten) wieder aktivieren, aber ich werde die Standardeinstellung verwenden:
ALTER TABLE Albums 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 | 1 | | FK_Albums_Genres | 0 | 0 | +-------------------+---------------+------------------+
Also, indem Sie faul (oder vergesslich) sind und WITH CHECK nicht explizit angeben , ist es mir erfolgreich gelungen, eine Einschränkung zu aktivieren, während der Status „nicht vertrauenswürdig“ erhalten bleibt.
Die wichtigste Erkenntnis daraus ist:Wenn Sie möchten, dass Ihren wieder aktivierten Einschränkungen vertraut wird, sollten Sie sie immer mit WITH CHECK aktivieren .
