इस तरह की समस्या को हल करने के तीन बुनियादी तरीके हैं क्योंकि CHECK बाधाओं को किसी क्वेरी पर आधारित नहीं किया जा सकता है।
विकल्प 1:ट्रिगर
सबसे सरल तरीका यह होगा कि TANK पर एक ट्रिगर लगाया जाए जो TANKS से पूछताछ करता है और यदि LEVEL क्षमता से अधिक हो जाता है तो एक अपवाद फेंकता है। हालांकि, इस तरह के सरलीकृत दृष्टिकोण के साथ समस्या यह है कि समवर्ती मुद्दों को सही ढंग से संभालना लगभग असंभव है। यदि सत्र 1 क्षमता कम करता है, तो सत्र 2 स्तर बढ़ाता है, और फिर दोनों लेनदेन प्रतिबद्ध हैं, ट्रिगर उल्लंघन का पता लगाने में सक्षम नहीं होंगे। यदि एक या दोनों तालिकाओं को शायद ही कभी संशोधित किया जाता है, तो यह कोई समस्या नहीं हो सकती है, लेकिन सामान्य तौर पर यह एक समस्या होने वाली है।
विकल्प 2:भौतिक दृश्य
आप TANK और TANKS तालिका में शामिल होने वाले ON COMMIT भौतिक दृश्य बनाकर समवर्ती समस्या को हल कर सकते हैं और फिर भौतिक दृश्य पर एक CHECK बाधा बना सकते हैं जो यह सत्यापित करता है कि LEVEL <=CAPACITY। भौतिक दृश्य में केवल डेटा होने से आप डेटा को दो बार संग्रहीत करने से बच सकते हैं जो बाधा का उल्लंघन करेगा। इसके लिए दोनों आधार तालिकाओं पर भौतिक दृश्य लॉग की आवश्यकता होगी जो आवेषण में थोड़ा सा ओवरहेड जोड़ देगा (हालांकि ट्रिगर्स का उपयोग करने से कम)। चेक को कमिट-टाइम पर धकेलने से समवर्ती समस्या का समाधान हो जाएगा, लेकिन यह एक अपवाद प्रबंधन समस्या का परिचय देता है क्योंकि COMMIT ऑपरेशन अब विफल हो सकता है क्योंकि भौतिक दृश्य ताज़ा विफल हो गया। आपके एप्लिकेशन को उस समस्या को संभालने और उपयोगकर्ता को उस तथ्य के प्रति सचेत करने में सक्षम होने की आवश्यकता होगी।
विकल्प 3:डेटा मॉडल बदलें
यदि आपके पास तालिका A में कोई मान है जो तालिका B की सीमा पर निर्भर करता है, तो यह संकेत दे सकता है कि B की सीमा तालिका A की विशेषता होनी चाहिए (बजाय या तालिका B की विशेषता होने के अतिरिक्त)। यह निश्चित रूप से आपके डेटा मॉडल की बारीकियों पर निर्भर करता है, लेकिन यह अक्सर विचार करने योग्य होता है।
