Ако имате CHECK ограничение в SQL Server, което в момента е деактивирано, можете да използвате кода по-долу, за да го активирате отново.
Когато активирате CHECK ограничение (или ограничение на външен ключ в този случай), имате възможност да укажете дали да проверите или не съществуващите данни в таблицата.
По-долу са дадени примери за код за активиране на CHECK ограничение, като посочва всяка от тези различни опции.
Пример 1 – Активиране на ограничение с помощта на WITH CHECK
Това е препоръчителният метод за активиране на вашия CHECK ограничения (освен ако нямате конкретна причина да не го използвате).
Ето пример за активиране на ограничение, наречено chkJobTitle :
ALTER TABLE Occupation WITH CHECK CHECK CONSTRAINT chkJobTitle;
Тук изрично посочвам WITH CHECK , което казва на SQL Server да провери съществуващите данни, преди да разреши ограничението. Ако някакви данни нарушават ограничението, ограничението няма да бъде активирано и ще получите грешка.
Това е добре, защото налага целостта на данните.
Когато създадете нов CHECK ограничение, това е настройката по подразбиране. Когато обаче активирате съществуващо ограничение (както правим тук), то не настройката по подразбиране.
Пример 2 – Активиране на ограничение с помощта на WITH NOCHECK
В този пример ограничението е активирано без проверка на съществуващите данни:
ALTER TABLE Occupation WITH NOCHECK CHECK CONSTRAINT chkJobTitle;
Тук изрично заявявам WITH NOCHECK , което казва на SQL Server да не проверява съществуващите данни. Това означава, че ограничението ще бъде активирано дори ако таблицата вече съдържа данни, които нарушават ограничението.
Това е настройката по подразбиране, когато активирате ограничение (но не и когато създавате такова).
Една от малкото причини (вероятно единствената причина) да използвате това е, ако искате да запазите невалидни данни в базата данни. Може би имате еднократно изключение, при което трябва да въведете ред или повече невалидни данни, но изисквате всички бъдещи данни да отговарят на ограничението.
Въпреки това, все още има рискове, свързани с това. Ето какво има да каже Microsoft за това:
Не препоръчваме да правите това, освен в редки случаи. Новото ограничение се оценява във всички по-късни актуализации на данни. Всички нарушения на ограниченията, които са потиснати от
WITH NOCHECKкогато се добави ограничението, може да доведе до неуспешни бъдещи актуализации, ако актуализират редове с данни, които не следват ограничението.
Така че използвайки WITH NOCHECK може потенциално да причини проблеми по-късно.
Пример 3 – Активиране на ограничение с помощта на опцията по подразбиране
Ето пример за използване на опцията по подразбиране:
ALTER TABLE Occupation CHECK CONSTRAINT chkJobTitle;
Този пример е еквивалент на предишния пример. Тъй като не посочих дали да проверя или не, SQL Server приема, че искам WITH NOCHECK .
Използването на WITH NOCHECK премахва доверието
Когато активирате ограничение с помощта на WITH NOCHECK , едно следствие, което трябва да знаете, е, че SQL Server вече не се доверява на това ограничение. Той го маркира като недоверен.
Да, правилно прочете. Всъщност има is_not_trusted флаг, който SQL Server задава на 1 когато деактивирате CHECK ограничение (което означава, че не е надеждно) и единственият начин да го настроите на 0 (доверен) е да посочите WITH CHECK при повторно активиране на ограничението. Използване на WITH NOCHECK просто не го реже.
Това е напълно логично. В крайна сметка, би ли ти вярвате ли на ограничение, което не е проверило всички данни?
С помощта на WITH CHECK , гарантирате, че ограничението проверява всички съществуващи данни, преди да бъде активирано. Единственият начин да бъде активиран е, ако всички съществуващи данни отговарят на ограничението. След като провери всички съществуващи данни, може да му се вярва.
За повече информация вижте Какво трябва да знаете за WITH NOCHECK, когато активирате ограничение CHECK в SQL Server, където можете да видите действителния is_not_trusted флагът се превключва напред-назад всеки път, когато деактивирам и активирам отново CHECK ограничение.
