Jeśli masz CHECK ograniczenie w SQL Server, które jest obecnie wyłączone, możesz użyć poniższego kodu, aby je ponownie włączyć.
Po włączeniu opcji CHECK ograniczenie (lub ograniczenie klucza obcego w tym przypadku), masz możliwość określenia, czy sprawdzić istniejące dane w tabeli.
Poniżej znajdują się przykłady kodu umożliwiające CHECK ograniczenie, określając każdą z tych różnych opcji.
Przykład 1 – Włącz wiązanie za pomocą WITH CHECK
Jest to zalecana metoda włączania funkcji CHECK ograniczenia (chyba że masz konkretny powód, aby go nie używać).
Oto przykład włączenia ograniczenia o nazwie chkJobTitle :
ALTER TABLE Occupation WITH CHECK CHECK CONSTRAINT chkJobTitle;
Tutaj wyraźnie stwierdzam WITH CHECK , który informuje SQL Server, aby sprawdził istniejące dane przed włączeniem ograniczenia. Jeśli jakiekolwiek dane naruszają ograniczenie, ograniczenie nie zostanie włączone i pojawi się błąd.
To dobrze, ponieważ wymusza integralność danych.
Kiedy tworzysz nowy CHECK ograniczenie, jest to ustawienie domyślne. Jednak po włączeniu istniejącego ograniczenia (tak jak robimy to tutaj) nie ustawienie domyślne.
Przykład 2 – Włącz wiązanie za pomocą funkcji WITH NOCHECK
W tym przykładzie ograniczenie jest włączone bez sprawdzania istniejących danych:
ALTER TABLE Occupation WITH NOCHECK CHECK CONSTRAINT chkJobTitle;
Tutaj wyraźnie stwierdzam WITH NOCHECK , który informuje SQL Server, aby nie sprawdzał istniejących danych. Oznacza to, że ograniczenie zostanie włączone, nawet jeśli tabela zawiera już dane, które naruszają ograniczenie.
Jest to ustawienie domyślne podczas włączania ograniczenia (ale nie podczas jego tworzenia).
Jednym z niewielu powodów (prawdopodobnie jedynym powodem), dla którego warto to wykorzystać, jest chęć przechowywania nieprawidłowych danych w bazie danych. Być może masz jednorazowy wyjątek, w którym musisz wprowadzić wiersz lub więcej nieprawidłowych danych, ale wszystkie przyszłe dane muszą być zgodne z ograniczeniem.
Jednak nadal istnieje ryzyko związane z robieniem tego. Oto, co Microsoft ma do powiedzenia na ten temat:
Nie zalecamy tego, z wyjątkiem rzadkich przypadków. Nowe ograniczenie jest oceniane we wszystkich późniejszych aktualizacjach danych. Wszelkie naruszenia ograniczeń, które są pomijane przez WITH NOCHECK po dodaniu ograniczenia może spowodować niepowodzenie przyszłych aktualizacji, jeśli zaktualizują one wiersze z danymi, które nie są zgodne z ograniczeniem.
Więc używając WITH NOCHECK może potencjalnie powodować problemy w przyszłości.
Przykład 3 – Włącz ograniczenie za pomocą opcji domyślnej
Oto przykład z użyciem domyślnej opcji:
ALTER TABLE Occupation CHECK CONSTRAINT chkJobTitle;
Ten przykład jest odpowiednikiem poprzedniego przykładu. Ponieważ nie określiłem, czy sprawdzać, czy nie, SQL Server zakłada, że chcę WITH NOCHECK .
Korzystanie z WITH NOCHECK usuwa zaufanie
Po włączeniu ograniczenia za pomocą WITH NOCHECK , jedną z konsekwencji, o której należy pamiętać, jest to, że SQL Server nie ufa już temu ograniczeniu. Oznacza to jako niezaufane.
Tak, dobrze to przeczytałeś. W rzeczywistości istnieje is_not_trusted flaga, którą SQL Server ustawia na 1 kiedy wyłączysz CHECK ograniczenie (co oznacza, że nie jest zaufane) i jedyny sposób na ustawienie go na 0 (zaufane) jest określenie WITH CHECK po ponownym włączeniu ograniczenia. Używanie WITH NOCHECK po prostu go nie wycina.
To ma sens. W końcu czy ty? zaufać ograniczeniu, które nie sprawdziło wszystkich danych?
Używając WITH CHECK , upewnij się, że ograniczenie sprawdza wszystkie istniejące dane przed włączeniem. Jedynym sposobem, w jaki można to włączyć, jest zgodność wszystkich istniejących danych z ograniczeniem. Po sprawdzeniu wszystkich istniejących danych można mu zaufać.
Aby uzyskać więcej informacji na ten temat, zobacz Co powinieneś wiedzieć o funkcji NOCHECK podczas włączania ograniczenia CHECK w SQL Server, gdzie możesz zobaczyć rzeczywisty is_not_trusted flaga jest przełączana tam iz powrotem za każdym razem, gdy wyłączam i ponownie włączam CHECK ograniczenie.
