SQL सर्वर में, एक विदेशी कुंजी बाधा (और एक 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 का उपयोग करके सक्षम करना चाहिए। ।
