क्या यह ओरेकल/एसक्यूएल में संभव है?

आपके द्वारा पोस्ट किए गए DDL पर कुछ टिप्पणियाँ।

कोई AUTOINCREMENT नहीं है ओरेकल में कीवर्ड। आपको एक अनुक्रम बनाना होगा (आमतौर पर प्रति तालिका एक क्रम) और NEXTVAL का उपयोग करना होगा अनुक्रम से या तो INSERT . में स्वयं कथन या सिंथेटिक प्राथमिक कुंजी को पॉप्युलेट करने के लिए ट्रिगर में।
ऐसा कुछ भी नहीं है जो VENUE_NO बना रहा हो EVENT_DETAILS में कॉलम . मुझे लगता है कि आपका वास्तविक डीडीएल उस कॉलम को परिभाषित कर रहा है।

आप इसे एक साधारण CHECK . के माध्यम से लागू नहीं कर सकते हैं बाधा आप एक ट्रिगर बना सकते हैं

CREATE OR REPLACE TRIGGER validate_capacity
  BEFORE INSERT OR UPDATE ON event_details
  FOR EACH ROW
DECLARE
  l_venue_capacity venue.capacity%type;
BEGIN
  SELECT capacity
    INTO l_venue_capacity
    FROM venue
   WHERE venue_no = :new.venue_no;

  IF( l_venue_capacity < :new.no_players )
  THEN
    RAISE_APPLICATION_ERROR( -20001, 'Sorry, the venue has insufficient capacity' );
  END IF;
END;

हालांकि, सावधान रहें कि

आपको VENUE . पर एक ट्रिगर भी रखना होगा तालिका जो यह देखने के लिए जाँच करती है कि क्या स्थल की क्षमता में परिवर्तन के कारण कुछ घटनाएँ अमान्य हो जाती हैं। आम तौर पर, इसके लिए घटना विवरण तालिका में किसी प्रकार की तारीख की आवश्यकता होती है, संभवतः, किसी स्थान की क्षमता समय के साथ बदल सकती है और आप वास्तव में केवल उस स्थान पर भविष्य की घटनाओं की जांच के लिए सत्यापन चाहते हैं।
ट्रिगर आधारित समाधान हमेशा बहु-उपयोगकर्ता वातावरण में काम नहीं करेंगे। कल्पना करें कि स्थल 1 की क्षमता 30 है। अब, सत्र A उस क्षमता को 15 तक अद्यतन करता है। लेकिन सत्र A के आने से पहले, सत्र B NO_PLAYERS के साथ एक ईवेंट सम्मिलित करता है 20 में से किसी भी सत्र के ट्रिगर में कोई समस्या नहीं दिखाई देगी, इसलिए दोनों परिवर्तनों की अनुमति होगी। लेकिन एक बार दोनों सत्र होने के बाद, एक आयोजन स्थल में 20 खिलाड़ियों के साथ बुक किया जाएगा जो केवल 15 खिलाड़ियों का समर्थन करता है। EVENT_DETAILS . पर ट्रिगर संभावित रूप से पंक्ति को VENUE . में लॉक कर सकता है इस दौड़ की स्थिति से बचने के लिए तालिका लेकिन वे आप EVENT_DETAILS पर प्रविष्टियां और अपडेट क्रमबद्ध कर रहे हैं तालिका जो एक प्रदर्शन समस्या हो सकती है, खासकर यदि आपका आवेदन कभी भी लेनदेन करने से पहले मानव इनपुट की प्रतीक्षा करता है।

ट्रिगर्स के विकल्प के रूप में, आप एक ON COMMIT . बना सकते हैं भौतिक दृश्य जो दो तालिकाओं को एक साथ जोड़ता है और एक CHECK डालता है उस भौतिक दृष्टिकोण पर प्रतिबंध जो इस आवश्यकता को लागू करता है कि खिलाड़ियों की संख्या स्थल क्षमता से अधिक नहीं हो सकती है। यह एक बहु-उपयोगकर्ता वातावरण में काम करेगा लेकिन इसके लिए दोनों आधार तालिकाओं पर भौतिक दृश्य लॉग की आवश्यकता होती है और यह चेक को उस बिंदु पर ले जाता है जहां सत्र प्रतिबद्ध होते हैं जो थोड़ा मुश्किल हो सकता है। अधिकांश एप्लिकेशन इस संभावना पर विचार नहीं करते हैं कि एक COMMIT कथन विफल हो सकता है इसलिए उन अपवादों को संभालना मुश्किल हो सकता है। और उपयोगकर्ता-इंटरफ़ेस के दृष्टिकोण से, उपयोगकर्ता को यह समझाना थोड़ा मुश्किल हो सकता है कि समस्या क्या है क्योंकि अपवाद लेनदेन में बहुत पहले किए गए परिवर्तनों से संबंधित हो सकता है।