यदि आपके पास SQL सर्वर में एक विदेशी कुंजी बाधा है जो वर्तमान में अक्षम है, तो आप इसे फिर से सक्षम करने के लिए नीचे दिए गए कोड का उपयोग कर सकते हैं।
जब आप एक विदेशी कुंजी बाधा को सक्षम करते हैं, तो आपके पास यह निर्दिष्ट करने का विकल्प होता है कि तालिका में किसी मौजूदा डेटा की जांच करनी है या नहीं। यह तब भी लागू होता है जब आप CHECK . को सक्षम करते हैं बाधा।
इन विभिन्न विकल्पों में से प्रत्येक को निर्दिष्ट करते हुए, एक विदेशी कुंजी बाधा को सक्षम करने के कोड उदाहरण नीचे दिए गए हैं।
उदाहरण 1 - चेक के साथ उपयोग करने में बाधा सक्षम करें
यह अनुशंसित विधि है (जब तक कि आपके पास इसका उपयोग न करने का कोई विशिष्ट कारण न हो)।
यहां FK_Albums_Artists नामक विदेशी कुंजी बाधा को सक्षम करने का एक उदाहरण दिया गया है :
ALTER TABLE Albums WITH CHECK CHECK CONSTRAINT FK_Albums_Artists;
यहां मैं स्पष्ट रूप से WITH CHECK बताता हूं , जो SQL सर्वर को बाधा को सक्षम करने से पहले मौजूदा डेटा की जांच करने के लिए कहता है। यदि कोई डेटा बाधा का उल्लंघन करता है, तो बाधा सक्षम नहीं होगी और आपको एक त्रुटि मिलेगी।
यह अच्छा है, क्योंकि यह संदर्भात्मक अखंडता को लागू करता है।
जब आप एक नई विदेशी कुंजी बाधा बनाते हैं, तो यह डिफ़ॉल्ट सेटिंग होती है। हालांकि, जब आप किसी मौजूदा बाधा को सक्षम करते हैं (जैसा कि हम यहां कर रहे हैं), यह नहीं है डिफ़ॉल्ट सेटिंग।
उदाहरण 2 - NOCHECK के साथ उपयोग करके एक बाधा सक्षम करें
इस उदाहरण में मौजूदा डेटा की जांच किए बिना बाधा सक्षम है:
ALTER TABLE Albums WITH NOCHECK CHECK CONSTRAINT FK_Albums_Artists;
यहां मैं स्पष्ट रूप से WITH NOCHECK state बताता हूं , जो SQL सर्वर को मौजूदा डेटा की जांच न करने के लिए कहता है। इसका मतलब है कि बाधा सक्षम हो जाएगी, भले ही तालिका में पहले से ही डेटा है जो बाधा का उल्लंघन करता है।
बाधा को सक्षम करते समय यह डिफ़ॉल्ट सेटिंग है (लेकिन एक बनाते समय नहीं)।
कुछ कारणों में से एक (शायद एकमात्र कारण) आप इसका उपयोग करेंगे यदि आप डेटाबेस में अमान्य डेटा रखना चाहते हैं। शायद आपके पास एक बार का अपवाद है जहां आपको एक पंक्ति या अधिक अमान्य डेटा दर्ज करना होगा, लेकिन आपको बाधा के अनुरूप भविष्य के सभी डेटा की आवश्यकता होगी।
हालांकि, ऐसा करने से जुड़े जोखिम अभी भी हैं। इस बारे में Microsoft का क्या कहना है:
<ब्लॉककोट>
दुर्लभ मामलों को छोड़कर, हम ऐसा करने की अनुशंसा नहीं करते हैं। बाद के सभी डेटा अपडेट में नई बाधा का मूल्यांकन किया जाता है। कोई भी बाधा उल्लंघन जो WITH NOCHECK . द्वारा दबा दिया गया है जब बाधा जोड़ी जाती है तो भविष्य के अपडेट विफल हो सकते हैं यदि वे डेटा के साथ पंक्तियों को अपडेट करते हैं जो बाधा का पालन नहीं करते हैं।
तो WITH NOCHECK का उपयोग कर रहे हैं संभावित रूप से बाद में समस्याएं पैदा कर सकता है।
उदाहरण 3 - डिफ़ॉल्ट विकल्प का उपयोग करके एक बाधा सक्षम करें
यहाँ डिफ़ॉल्ट विकल्प का उपयोग करते हुए एक उदाहरण दिया गया है:
ALTER TABLE Albums CHECK CONSTRAINT FK_Albums_Artists;
यह उदाहरण पिछले उदाहरण के बराबर है। चूँकि मैंने यह निर्दिष्ट नहीं किया था कि जाँच करनी है या नहीं, SQL सर्वर मानता है कि मुझे WITH NOCHECK चाहिए .
इसलिए स्पष्ट रूप से WITH CHECK निर्दिष्ट करना सुनिश्चित करें यदि आप संदर्भात्मक अखंडता के मुद्दों से बचना चाहते हैं।
NOCHECK के साथ उपयोग करने से विश्वास हट जाता है
जब आप (डिफ़ॉल्ट) WITH NOCHECK . का उपयोग करके एक बाधा को सक्षम करते हैं , एक परिणाम के बारे में आपको अवगत होना चाहिए कि SQL सर्वर अब उस बाधा पर भरोसा नहीं करेगा। यह इसे विश्वसनीय नहीं के रूप में चिह्नित करता है। वास्तव में, जब आप बाधा को अक्षम करते हैं तो इसे पहले से ही विश्वसनीय नहीं के रूप में चिह्नित किया जाता है।
SQL सर्वर में एक is_not_trusted है फ़्लैग करें जिसे वह 1 . पर सेट करता है जब आप एक विदेशी कुंजी बाधा को अक्षम करते हैं (जिसका अर्थ है कि यह विश्वसनीय नहीं है), और इसे 0 पर सेट करने का एकमात्र तरीका है (विश्वसनीय) WITH CHECK निर्दिष्ट करना है बाधा को पुन:सक्षम करते समय। दूसरी ओर, WITH NOCHECK . का उपयोग करते हुए मौजूदा डेटा की जांच किए बिना बस इसे सक्षम करता है।
WITH CHECK . का उपयोग करके , आप सुनिश्चित करते हैं कि बाधा सक्षम होने से पहले सभी मौजूदा डेटा की जांच करती है। इसे सक्षम करने का एकमात्र तरीका यह है कि यदि सभी मौजूदा डेटा बाधा के अनुरूप हों। एक बार जब यह सभी मौजूदा डेटा की जांच कर लेता है, तो बाधा पर भरोसा किया जा सकता है।
उदाहरण 4 - विश्वसनीय/अक्षम स्थिति जांचें
आप 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 | 0 | 1 | | FK_Albums_Genres | 0 | 0 | +-------------------+---------------+------------------+
यह मुझे बताता है कि पिछले उदाहरण में मैंने जो बाधा सक्षम की थी ( FK_Albums_Artists ) विश्वसनीय नहीं है।
ऐसा इसलिए है क्योंकि मैंने इसे डिफ़ॉल्ट सेटिंग का उपयोग करके सक्षम किया है, जो कि WITH NOCHECK . है .
अगर मैं इसे WITH CHECK . का उपयोग करके फिर से सक्षम करता हूं , यहाँ क्या होता है:
ALTER TABLE Albums WITH CHECK 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 | 0 | | FK_Albums_Genres | 0 | 0 | +-------------------+---------------+------------------+
सौभाग्य से इस मामले में मेरे पास कोई डेटा नहीं था जो बाधा का उल्लंघन करता था, इसलिए बाधा को सफलतापूर्वक सक्षम किया गया था और इसका विश्वास बहाल किया गया था।
यदि कोई डेटा था जो बाधा का उल्लंघन करता था, तो एक त्रुटि प्रदर्शित होती, और इससे पहले कि मैं बाधा में विश्वास बहाल कर पाता, मुझे डेटा को ठीक करने के लिए मजबूर किया जाएगा।
