सवाल और परिदृश्य
एक लीगेसी orders टेबल में बिना किसी पैरेंट ग्राहक के थोड़ी संख्या में customer_id मान मौजूद हैं। टीम PostgreSQL 18 में इस संबंध को घोषित करना चाहती है ताकि टारगेट स्कीमा स्पष्ट हो सके, बिना ऐतिहासिक डेटा के वन-शॉट सुधार को रोके। यह तय करें कि क्या NOT ENFORCED उपयुक्त है, बताएं कि यह एक सामान्य फॉरेन की से कैसे भिन्न है, उल्लंघनों को खोजने का तरीका दिखाएं, और एक चरणबद्ध स्विच के साथ यह प्रमाण परिभाषित करें कि डेटा तैयार है।
साक्षात्कारकर्ता क्या जांच रहा है
- एक घोषित व्यावसायिक इरादे और अमान्य राइट्स (writes) के डेटाबेस अस्वीकृति के बीच अंतर करना।
- यह समझाना कि
NOT ENFORCEDराइट्स की जांच नहीं करता है और इसलिए यह रनटाइम अखंडता की पूर्ण गारंटी नहीं है। - ऐतिहासिक स्कैन, इंक्रीमेंटल निगरानी, रिपेयर बैच और एक अंतिम स्विच गेट को डिजाइन करना।
- डंप, रिस्टोर, क्रॉस-सर्विस राइटर्स, रोलबैक और क्लाइंट संगतता जोखिमों की पहचान करना।
- यह समझाना कि एक असत्यापित कंस्ट्रेंट को क्वेरी-ऑप्टिमाइज़र धारणा के रूप में क्यों नहीं माना जाना चाहिए।
उत्तर देने से पहले स्पष्टीकरण संबंधी प्रश्न
- क्या यह एक फॉरेन की है या CHECK? उल्लंघन की मात्रा, वृद्धि दर और सुधार का स्वामी (owner) कौन है?
- क्या राइट्स केवल PostgreSQL तक सीमित हैं, या क्या ETL जॉब्स, बैच स्क्रिप्ट्स और डायरेक्ट टूल्स एप्लिकेशन को बायपास करते हैं?
- क्या लीगेसी क्लाइंट्स नए कंस्ट्रेंट नाम, माइग्रेशन लॉक और विफल स्विच को संभाल सकते हैं?
- क्या अंतिम स्विच के लिए शून्य उल्लंघन तक पहुंचना आवश्यक है, या यह किरायेदार-दर-किरायेदार (tenant by tenant) पूरा हो सकता है?
- क्या सबूत साबित करता है कि प्रत्येक पार्टीशन और वॉटरमार्क को स्कैन किया गया था?
30-सेकंड का उत्तर ढांचा
"NOT ENFORCED लीगेसी डर्टी डेटा के बने रहने के दौरान CHECK या फॉरेन-की इरादे को घोषित करने के लिए उपयोगी है; PostgreSQL इसके लिए नए राइट्स की जांच नहीं करेगा, इसलिए यह अखंडता की गारंटी नहीं है। मैं एक पूर्ण उल्लंघन आधार रेखा (baseline) स्थापित करूंगा, नए राइट्स के लिए इंक्रीमेंटल जांच और अलर्ट चलाऊंगा, ऐतिहासिक पंक्तियों की मरम्मत या क्वारंटाइन करूंगा, और शून्य उल्लंघन तथा रिस्टोर ड्रिल के बाद ही enforced पर स्विच करूंगा। परिवर्तन के दौरान, क्लाइंट्स और ऑप्टिमाइज़र्स को इस घोषणा को सत्यापित सत्य नहीं मानना चाहिए।"
चरण-दर-चरण विस्तृत उत्तर
शब्दार्थ और जोखिम बताएं
PostgreSQL 18 CHECK और फॉरेन-की कंस्ट्रेंट्स को NOT ENFORCED के रूप में निर्दिष्ट करने की अनुमति देता है। डेटाबेस घोषणा को संग्रहीत करता है लेकिन राइट्स की जांच वैसे नहीं करता जैसा कि वह एक लागू (enforced) कंस्ट्रेंट के लिए करता। मेटाडेटा प्रलेखन, प्रशासन और माइग्रेशन समन्वय का समर्थन करता है; यह एप्लिकेशन, ETL या स्वतंत्र डेटा-गुणवत्ता जांच का स्थान नहीं लेता है।
पूर्ण और इंक्रीमेंटल साक्ष्य बनाएं
फॉरेन की के लिए, पैरेंट के बिना चाइल्ड पंक्तियों को खोजने के लिए एक एंटी-जॉइन चलाएं; CHECK के लिए, विधेय (predicate) का निषेध चलाएं। स्कैन समय, स्नैपशॉट या वॉटरमार्क, पार्टीशन रेंज और परिणाम डाइजेस्ट रिकॉर्ड करें। फिर CDC, राइट जॉब्स या गुणवत्ता कार्यों में इन्सर्ट और अपडेट की जांच करें ताकि एक बार का ऐतिहासिक स्कैन एक नया बायपास पथ न छिपा सके।
SELECT o.order_id, o.customer_id
FROM orders AS o
LEFT JOIN customers AS c ON c.customer_id = o.customer_id
WHERE o.customer_id IS NOT NULL
AND c.customer_id IS NULL;सुधार और स्विच गेट्स डिज़ाइन करें
अनाथ ऑर्डर्स को स्वचालित रूप से मरम्मत योग्य, व्यावसायिक पुष्टि की आवश्यकता वाले, या क्वारंटाइन की आवश्यकता वाले के रूप में वर्गीकृत करें। सुधार को एक आइडम्पोटेंसी कुंजी, बैच सीमा और स्टॉप स्थिति दें। स्विच करने से पहले, एक शून्य पूर्ण स्कैन, एक स्वच्छ इंक्रीमेंटल विंडो, एक सफल बैकअप-और-रिस्टोर ड्रिल और प्रत्येक राइटर के कवरेज की आवश्यकता होती है। कम ट्रैफ़िक वाली विंडो में enforced माइग्रेशन चलाएं और लॉक प्रतीक्षा तथा त्रुटि दरों पर नज़र रखें।
रिकवरी और वातावरण के अंतर (drift) को संभालें
यदि माइग्रेशन विफल हो जाता है, तो NOT ENFORCED घोषणा और सुधारे गए रिकॉर्ड्स को बनाए रखें, एप्लिकेशन रिलीज़ और गुणवत्ता कार्य को वापस रोल करें, और यह दावा न करें कि कंस्ट्रेंट लागू है। डंप, रिस्टोर, रीड रेप्लिका, आपदा-पुनर्प्राप्ति (disaster-recovery) क्लस्टर और पुराने क्लाइंट्स का परीक्षण करें। पुष्टि करें कि लक्ष्य परिवेश केवल ORM प्रदर्शन पर भरोसा करने के बजाय conenforced मेटाडेटा को समझते हैं।
उच्च-गुणवत्ता वाला नमूना उत्तर
"मैं NOT ENFORCED को एक माइग्रेशन अनुबंध मानता हूं, न कि डेटाबेस सुरक्षा उपाय। मैं ऑर्डर्स और ग्राहकों पर एक पूर्ण एंटी-जॉइन चलाऊंगा, पार्टीशन और वॉटरमार्क रिकॉर्ड करूंगा, फिर CDC को नए राइट्स की जांच करने दूंगा। अनाथों को स्वचालित सुधार, व्यावसायिक पुष्टि और क्वारंटाइन में वर्गीकृत किया जाता है, जिसमें आइडम्पोटेंट रीप्ले होता है। पूर्ण और इंक्रीमेंटल जांच साफ होने, रिस्टोर परीक्षण पास होने और प्रत्येक राइटर के कवर होने के बाद ही मैं कम-ट्रैफ़िक विंडो में फॉरेन की को enforced में बदलूंगा और लॉक प्रतीक्षा की निगरानी करूंगा। किसी भी समय कोई क्लाइंट या क्वेरी ऑप्टिमाइज़र यह नहीं मानेगा कि घोषणा अखंडता को साबित करती है।"
सामान्य गलतियां
- त्रुटि: स्कीमा में एक फॉरेन की देखना और यह मान लेना कि डेटा सुसंगत है → यह विफल क्यों होता है:
NOT ENFORCEDराइट्स की जांच नहीं करता है → सुधार: पूर्ण और इंक्रीमेंटल गुणवत्ता साक्ष्य प्रस्तुत करें। - त्रुटि: ऐतिहासिक तालिका को एक बार स्कैन करना → यह विफल क्यों होता है: एक नया बायपास राइटर उल्लंघन पैदा कर सकता है → सुधार: CDC, ETL, स्क्रिप्ट्स और एप्लिकेशन राइट्स को कवर करें।
- त्रुटि: सीधे enforced पर स्विच करना → यह विफल क्यों होता है: डर्टी डेटा या लॉक माइग्रेशन को निरस्त कर सकते हैं → सुधार: मरम्मत करें, पूर्वाभ्यास करें, गेट करें, फिर कम ट्रैफ़िक वाली विंडो में स्विच करें।
- त्रुटि: एक गैर-लागू घोषणा को अनुकूलन संकेत के रूप में मानना → यह विफल क्यों होता है: एक घोषणा अखंडता का प्रमाण नहीं है → सुधार: केवल सत्यापित सांख्यिकी और समर्थित डेटाबेस व्यवहार पर भरोसा करें।
अनुवर्ती प्रश्न और उत्तर
क्या कोई CHECK कंस्ट्रेंट क्रॉस-टेबल नियम के लिए किसी अन्य टेबल का संदर्भ ले सकता है?
इस पर भरोसा न करें। एक पंक्ति-स्तरीय CHECK अन्य पंक्तियों के बदलने के बाद वैश्विक स्थिति की गारंटी नहीं दे सकता है, और डंप/रिस्टोर क्रम इस दोष को उजागर कर सकता है। क्रॉस-टेबल संबंधों के लिए फॉरेन की या स्वतंत्र गुणवत्ता कार्य को प्राथमिकता दें।
क्या होगा यदि उल्लंघन की संख्या कभी शून्य तक नहीं पहुंचती है?
NOT ENFORCED को बनाए रखें, उल्लंघनों को क्वारंटाइन या स्पष्ट व्यावसायिक-अपवाद सूची में रखें, और एक वृद्धि सीमा, स्वामी और समाप्ति तिथि निर्धारित करें। यदि कंस्ट्रेंट निकट-अवधि के निष्पादन योग्य अनुबंध के बजाय दस्तावेज़ीकरण है, तो पुनर्मूल्यांकन करें कि क्या यह स्कीमा से संबंधित है।
क्या एप्लिकेशन सत्यापन लागू फॉरेन की का स्थान ले सकता है?
केवल एक संक्रमण या पूरक के रूप में। एकाधिक राइटर्स, समवर्तीता और सीधी स्क्रिप्ट्स एप्लिकेशन जांच को बायपास करती हैं; अंतिम अखंडता सीमा एक डेटाबेस कंस्ट्रेंट या एक सत्यापन योग्य डेटा पाइपलाइन होनी चाहिए।
आप कैसे साबित करते हैं कि आपदा-पुनर्प्राप्ति (DR) रेप्लिका में अंतर (drift) नहीं आया है?
प्राथमिक और पुनर्स्थापित रेप्लिका पर समान गुणवत्ता क्वेरी चलाएं, वॉटरमार्क, उल्लंघन गणना और परिणाम डाइजेस्ट की तुलना करें, और स्विच गेट में रिस्टोर ड्रिल शामिल करें।
संदर्भ
- PostgreSQL प्रलेखन 18: कंस्ट्रेंट्स
- PostgreSQL प्रलेखन 18: CREATE TABLE
- PostgreSQL प्रलेखन 18: रिलीज़ नोट्स
- ग्रेग लो: SQL साक्षात्कार: 64 कंस्ट्रेंट्स को अक्षम और पुनः सक्षम करना
- MockIF: SQL साक्षात्कार प्रश्न 2026
उत्तर देने की युक्ति
बताएं कि NOT ENFORCED राइट्स की जांच किए बिना एक कंस्ट्रेंट घोषित करता है, फिर बेसलाइन, इंक्रीमेंटल मॉनिटरिंग, रिपेयर क्लासेस, स्विच गेट और रिस्टोर साक्ष्य प्रदान करें।
एक वाक्य में निष्कर्ष
NOT ENFORCED एक दृश्यमान माइग्रेशन अनुबंध है; लागू रनटाइम सुरक्षा को अपनाने से पहले डेटा इंजीनियरों को अभी भी स्वतंत्र साक्ष्य की आवश्यकता होती है।