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