In SQL Server is een externe sleutelbeperking (en een CHECK beperking) kan worden vertrouwd of niet vertrouwd.
Wanneer een beperking wordt vertrouwd, betekent dit dat de beperking door het systeem is geverifieerd. Als het niet vertrouwd is, heeft de beperking niet geverifieerd door het systeem.
Kortom, als u een niet-vertrouwde beperking heeft, kunt u ook ongeldige gegevens in uw database hebben. Hiermee bedoel ik dat u gegevens zou kunnen hebben die de beperking schenden.
Dit betekent dat u niet langer referentiële integriteit binnen uw relaties handhaaft, wat normaal gesproken geen goede gewoonte is bij het verzorgen van een relationele database in productie.
In dit artikel zal ik mijn bestaande beperkingen controleren op hun "betrouwbaarheid", en dan zal ik ze bijwerken om opnieuw betrouwbaar te worden.
Voorbeeld 1 – Bestaande beperkingen beoordelen
U kunt erachter komen of een beperking al dan niet wordt vertrouwd door de sys.foreign_keys op te vragen. systeemweergave.
Zoals dit:
SELECT name AS 'Constraint', is_disabled, is_not_trusted FROM sys.foreign_keys;
Resultaat:
+-------------------+---------------+------------------+ | Constraint | is_disabled | is_not_trusted | |-------------------+---------------+------------------| | FK_Albums_Artists | 1 | 1 | | FK_Albums_Genres | 0 | 1 | +-------------------+---------------+------------------+
OK, dus dit zegt me dat ik twee externe sleutelbeperkingen heb en dat ze allebei niet vertrouwd zijn.
Een van de beperkingen is uitgeschakeld, dus het is logisch dat deze niet wordt vertrouwd (slechte gegevens kunnen de database binnenkomen wanneer de beperking is uitgeschakeld).
Maar de andere beperking is ingeschakeld, dus deze mag niet worden vertrouwd. Niet-vertrouwd zijn betekent dat er ongeldige gegevens in de database kunnen zijn. Het betekent niet dat er is ongeldige gegevens, alleen dat er zou zijn.
Kortom, door te zijn ingeschakeld, controleert het toekomstige gegevens, maar het kan niet instaan voor bestaande gegevens. Als een beperking wordt vertrouwd, kunt u er zeker van zijn dat alle bestaande gegevens geldig zijn.
Alleen niet-vertrouwde beperkingen retourneren
Misschien vindt u het prettiger om een WHERE . te gebruiken clausule om alleen de niet-vertrouwde beperkingen te retourneren. Zoals dit:
SELECT name AS 'Constraint', is_disabled, is_not_trusted FROM sys.foreign_keys WHERE is_not_trusted = 1;
Resultaat:
+-------------------+---------------+------------------+ | Constraint | is_disabled | is_not_trusted | |-------------------+---------------+------------------| | FK_Albums_Artists | 1 | 1 | | FK_Albums_Genres | 0 | 1 | +-------------------+---------------+------------------+
Dus in dit geval is het resultaat hetzelfde (omdat alle huidige beperkingen niet worden vertrouwd).
Voorbeeld 2 – Vertrouwen herstellen
Om het vertrouwen van uw ingeschakelde beperking te herstellen, schakelt u deze eenvoudig opnieuw in terwijl u de WITH CHECK gebruikt optie.
Zoals dit:
ALTER TABLE Albums WITH CHECK CHECK CONSTRAINT FK_Albums_Genres;
Wanneer we nu sys.foreign_keys query opvragen we krijgen een ander resultaat:
SELECT name AS 'Constraint', is_disabled, is_not_trusted FROM sys.foreign_keys;
Resultaat:
+-------------------+---------------+------------------+ | Constraint | is_disabled | is_not_trusted | |-------------------+---------------+------------------| | FK_Albums_Artists | 1 | 1 | | FK_Albums_Genres | 0 | 0 | +-------------------+---------------+------------------+
We kunnen zien dat de beperking nu vertrouwd is, omdat de is_not_trusted vlag is ingesteld op 0 .
Voorbeeld 3 – Hoe werd de beperking niet vertrouwd?
Wanneer u een externe-sleutelbeperking uitschakelt, wordt deze automatisch niet vertrouwd. Wanneer u dezelfde beperking opnieuw inschakelt, heeft u de mogelijkheid om het vertrouwen ervan te herstellen. Als u dit niet doet, blijft het onbetrouwbaar.
Wanneer u een externe sleutelbeperking inschakelt, heeft u de mogelijkheid om WITH CHECK op te geven of WITH NOCHECK . Als u het laatste opgeeft, blijft uw beperking niet vertrouwd zodra deze is ingeschakeld.
Het is belangrijk op te merken dat WITH NOCHECK is de standaardoptie, dus als u niet expliciet opgeeft dat deze moet worden vertrouwd, wordt de beperking ingeschakeld als niet-vertrouwd.
Het is echter het tegenovergestelde wanneer u een externe sleutelbeperking maakt. Wanneer u de beperking voor het eerst maakt, is de standaardoptie WITH CHECK . Dus als u deze instelling weglaat, wordt deze standaard vertrouwd (tenzij u ongeldige gegevens heeft, in welk geval deze niet wordt ingeschakeld). U kunt deze instelling echter overschrijven door WITH NOCHECK expliciet op te geven wanneer u de beperking maakt.
Om te laten zien hoe uw ingeschakelde beperkingen gemakkelijk niet vertrouwd kunnen blijven, zal ik de andere sleutel (de uitgeschakelde) opnieuw inschakelen, maar ik gebruik de standaardinstelling:
ALTER TABLE Albums CHECK CONSTRAINT FK_Albums_Artists; SELECT name AS 'Constraint', is_disabled, is_not_trusted FROM sys.foreign_keys;
Resultaat:
+-------------------+---------------+------------------+ | Constraint | is_disabled | is_not_trusted | |-------------------+---------------+------------------| | FK_Albums_Artists | 0 | 1 | | FK_Albums_Genres | 0 | 0 | +-------------------+---------------+------------------+
Dus door lui (of vergeetachtig) te zijn en niet expliciet WITH CHECK op te geven , ben ik erin geslaagd een beperking in te schakelen terwijl de status 'niet vertrouwd' intact bleef.
De belangrijkste conclusie hiervan is:als u wilt dat uw opnieuw ingeschakelde beperkingen worden vertrouwd, moet u ze altijd inschakelen met WITH CHECK .