Sådan gendannes tilliden til en fremmednøglebegrænsning i SQL Server (T-SQL-eksempler)

I SQL Server, en fremmednøgle-begrænsning (og en CHECK constraint) kan enten være tillid til eller ikke have tillid til.

Når der er tillid til en begrænsning, betyder det, at begrænsningen er blevet verificeret af systemet. Når den ikke er tillid til, har begrænsningen ikke blevet verificeret af systemet.

Dybest set, når du har en upålidelig begrænsning, kan du også have ugyldige data i din database. Med dette mener jeg, at du kan have data, der overtræder begrænsningen.

Det betyder, at du ikke længere opretholder referentiel integritet i dine relationer, hvilket normalt ikke er god praksis, når du passer på en relationel database i produktion.

I denne artikel vil jeg tjekke mine eksisterende begrænsninger for deres "pålidelighed", og derefter vil jeg opdatere dem for at blive troværdige igen.

Eksempel 1 – Gennemgå eksisterende begrænsninger

Du kan finde ud af, om der er tillid til en begrænsning eller ej, ved at forespørge på sys.foreign_keys systemvisning.

Sådan:

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

Resultat:

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

OK, så det fortæller mig, at jeg har to begrænsninger for fremmednøgler, og at der ikke er tillid til dem begge.

En af begrænsningerne er deaktiveret, så det giver mening, at den ikke er tillid til (dårlige data kan komme ind i databasen, når begrænsningen er deaktiveret).

Men den anden begrænsning er aktiveret, så den burde virkelig ikke være tillid til. At være upålidelig betyder, at der kan være ugyldige data i databasen. Det betyder ikke, at der er ugyldige data, bare at der kunne være.

Grundlæggende vil den ved at være aktiveret kontrollere fremtidige data, men den kan ikke stå inde for eksisterende data. Hvis der er tillid til en begrænsning, kan du være sikker på, at alle eksisterende data er gyldige.

Returnering kun upålidelige begrænsninger

Måske foretrækker du at bruge en WHERE klausul for kun at returnere de upålidelige begrænsninger. Sådan:

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

Resultat:

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

Så i dette tilfælde er resultatet det samme (fordi alle nuværende begrænsninger er upålidelige).

Eksempel 2 – Gendan tillid

For at genoprette tilliden til din aktiverede begrænsning skal du blot genaktivere den, mens du bruger WITH CHECK mulighed.

Sådan:

ALTER TABLE Albums 
WITH CHECK CHECK CONSTRAINT FK_Albums_Genres;

Når vi nu forespørger sys.foreign_keys vi får et andet resultat:

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

Resultat:

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

Vi kan se, at begrænsningen nu er tillid til, fordi is_not_trusted flag er sat til 0 .

Eksempel 3 – Hvordan blev begrænsningen upålidelig?

Når du deaktiverer en begrænsning af en fremmednøgle, bliver den automatisk upålidelig. Når du genaktiverer den samme begrænsning, har du mulighed for at genoprette dens tillid. Hvis du ikke gør dette, vil den forblive upålidelig.

Når du aktiverer en fremmednøglebegrænsning, har du mulighed for at angive WITH CHECK eller WITH NOCHECK . Hvis du angiver det senere, vil din begrænsning forblive upålidelig, når den er blevet aktiveret.

Det er vigtigt at bemærke, at WITH NOCHECK er standardindstillingen, så hvis du ikke udtrykkeligt angiver, at den skal have tillid til, vil begrænsningen blive aktiveret som upålidelig.

Det er dog det modsatte, når du opretter en fremmednøglebegrænsning. Når du først opretter begrænsningen, er standardindstillingen WITH CHECK . Så hvis du udelader denne indstilling, vil den som standard være tillid til (medmindre du har ugyldige data, i hvilket tilfælde de ikke vil blive aktiveret). Du kan dog tilsidesætte denne indstilling ved eksplicit at angive WITH NOCHECK når du opretter begrænsningen.

For at demonstrere, hvordan dine aktiverede begrænsninger nemt kan forblive upålidelige, genaktiverer jeg den anden nøgle (den deaktiverede), men jeg bruger standardindstillingen:

ALTER TABLE Albums 
CHECK CONSTRAINT FK_Albums_Artists;

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

Resultat:

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

Så ved at være doven (eller glemsom) og ikke eksplicit specificere WITH CHECK , lykkedes det mig at aktivere en begrænsning, samtidig med at dens status "ikke betroet" blev intakt.

Det vigtigste ved dette er:Hvis du vil have tillid til dine genaktiverede begrænsninger, bør du altid aktivere dem ved hjælp af WITH CHECK .