Как да възстановим доверието в ограничение на външния ключ в SQL Server (примери за T-SQL)

В SQL Server ограничение за външен ключ (и CHECK ограничение) може да се има доверие или да не се вярва.

Когато ограничението е доверено, това означава, че ограничението е проверено от системата. Когато не е надеждно, ограничението не е потвърдено от системата.

По принцип, когато имате ненадеждно ограничение, можете също да имате невалидни данни във вашата база данни. С това имам предвид, че бихте могли да имате данни, които нарушават ограничението.

Това означава, че вече не поддържате референтна цялост във вашите взаимоотношения, което обикновено не е добра практика, когато се грижите за релационна база данни в производството.

В тази статия ще проверя съществуващите си ограничения за тяхната „надеждност“ и след това ще ги актуализирам, за да станат надеждни отново.

Пример 1 – Преглед на съществуващите ограничения

Можете да разберете дали дадено ограничение е надеждно или не, като потърсите sys.foreign_keys системен изглед.

Като това:

SELECT 
  name AS 'Constraint',
  is_disabled,
  is_not_trusted
FROM sys.foreign_keys;

Резултат:

+-------------------+---------------+------------------+
| Constraint        | is_disabled   | is_not_trusted   |
|-------------------+---------------+------------------|
| FK_Albums_Artists | 1             | 1                |
| FK_Albums_Genres  | 0             | 1                |
+-------------------+---------------+------------------+

Добре, това ми казва, че имам две ограничения за външни ключове и двете не са надеждни.

Едно от ограниченията е деактивирано, така че има смисъл да не му се вярва (лошите данни могат да влязат в базата данни всеки път, когато ограничението е деактивирано).

Но другото ограничение е активирано, така че наистина не трябва да има доверие. Това, че нямате доверие, означава, че може да има невалидни данни в базата данни. Това не означава, че има невалидни данни, само че може бъда.

По принцип, като бъде активиран, той ще проверява бъдещи данни, но не може да гарантира съществуващи данни. Ако ограничението е надеждно, тогава можете да сте сигурни, че всички съществуващи данни са валидни.

Върнете само ненадеждни ограничения

Може да предпочетете да използвате WHERE клауза за връщане само на недоверените ограничения. Като това:

SELECT 
  name AS 'Constraint',
  is_disabled,
  is_not_trusted
FROM sys.foreign_keys
WHERE is_not_trusted = 1;

Резултат:

+-------------------+---------------+------------------+
| Constraint        | is_disabled   | is_not_trusted   |
|-------------------+---------------+------------------|
| FK_Albums_Artists | 1             | 1                |
| FK_Albums_Genres  | 0             | 1                |
+-------------------+---------------+------------------+

Така че в този случай резултатът е същият (тъй като всички текущи ограничения не са надеждни).

Пример 2 – Възстановяване на доверието

За да възстановите доверието във вашето активирано ограничение, просто го активирайте отново, докато използвате WITH CHECK опция.

Като това:

ALTER TABLE Albums 
WITH CHECK CHECK CONSTRAINT FK_Albums_Genres;

Сега, когато правим заявка за sys.foreign_keys получаваме различен резултат:

SELECT 
  name AS 'Constraint',
  is_disabled,
  is_not_trusted
FROM sys.foreign_keys;

Резултат:

+-------------------+---------------+------------------+
| Constraint        | is_disabled   | is_not_trusted   |
|-------------------+---------------+------------------|
| FK_Albums_Artists | 1             | 1                |
| FK_Albums_Genres  | 0             | 0                |
+-------------------+---------------+------------------+

Можем да видим, че ограничението вече е доверено, тъй като is_not_trusted флагът е настроен на 0 .

Пример 3 – Как ограничението стана ненадеждно?

Когато деактивирате ограничение за външен ключ, то автоматично става ненадеждно. Когато активирате отново същото ограничение, имате възможност да възстановите доверието му. Ако не направите това, то ще остане ненадеждно.

Когато активирате ограничение за външен ключ, имате възможност да посочите WITH CHECK или WITH NOCHECK . Ако посочите по-късното, вашето ограничение ще остане ненадеждно, след като бъде активирано.

Важно е да се отбележи, че WITH NOCHECK е опцията по подразбиране, така че ако не посочите изрично, че трябва да има доверие, ограничението ще бъде активирано като ненадеждно.

Обратното е обаче, когато създавате ограничение за външен ключ. Когато за първи път създадете ограничението, опцията по подразбиране е WITH CHECK . Така че, ако пропуснете тази настройка, тя ще бъде надеждна по подразбиране (освен ако нямате невалидни данни, в който случай тя няма да бъде активирана). Можете обаче да замените тази настройка, като изрично посочите WITH NOCHECK когато създадете ограничението.

За да демонстрирам как вашите активирани ограничения могат лесно да останат ненадеждни, ще активирам отново другия ключ (деактивирания), но ще използвам настройката по подразбиране:

ALTER TABLE Albums 
CHECK CONSTRAINT FK_Albums_Artists;

SELECT 
  name AS 'Constraint',
  is_disabled,
  is_not_trusted
FROM sys.foreign_keys;

Резултат:

+-------------------+---------------+------------------+
| Constraint        | is_disabled   | is_not_trusted   |
|-------------------+---------------+------------------|
| FK_Albums_Artists | 0             | 1                |
| FK_Albums_Genres  | 0             | 0                |
+-------------------+---------------+------------------+

Така че като сте мързеливи (или забравящи) и не указвате изрично WITH CHECK , успешно успях да активирам ограничение, като същевременно запазих непокътнат статуса му „не се доверява“.

Основният извод от това е:ако искате вашите повторно активирани ограничения да бъдат доверени, винаги трябва да ги активирате с помощта на WITH CHECK .