मेरे पास 2 टेबल वाला डेटाबेस है (प्राथमिक कुंजी इटैलिक में हैं):

  • कमरा (ROOM_ID, दिन, घंटा)
  • आरक्षण (CUSTOMER_ID, ROOM_ID, दिनांक)

पहली तालिका कमरे की उपलब्धता और दूसरी ग्राहकों द्वारा किए गए आरक्षणों का वर्णन करती है।

अब मान लें कि मैंने ROOM में 3 पंक्तियां डाली हैं:

3898   WEDNESDAY   2.00
3454   MONDAY      1.00
3563   MONDAY      1.00

और दो पंक्तियों में RESERVATION:

0898   3454   05-09-2019 
0567   3898   05-08-2019  

अब मैं एक बाधा पैदा करना चाहता हूं जो एक ऐसे ग्राहक को अनुमति नहीं देता है जिसने पहले से ही एक कमरा आरक्षित करने के लिए एक कमरा आरक्षित किया है जो एक ही समय में उपलब्ध है!

फिर अगर मैं सम्मिलित करने का प्रयास करता हूं:

0567   3563   05-10-2019  

मुझे एक त्रुटि मिलेगी क्योंकि पहले टेबल रूम के अनुसार 3454 और 3563 दोनों 1.00 बजे उपलब्ध हैं।

धन्यवाद !

0
user10795185 5 अप्रैल 2020, 12:15
1
मुझे लगता है कि ट्रिगर होने का एकमात्र स्वचालित समाधान होगा, जिसकी मैं अनुशंसा नहीं करता हूं। यह कुछ ऐसा है जिसे आपको या तो अपने आवेदन में या संग्रहित प्रक्रिया के अंदर जांचना चाहिए जो सम्मिलित करता है।
 – 
user12493039
5 अप्रैल 2020, 12:20
1
MYSQL और SQLSERVER बहुत अलग हैं। आपको अनुचित टैग हटा देना चाहिए या यदि आप दोनों के लिए समाधान चाहते हैं तो आपको ऐसा कहना चाहिए।
 – 
P.Salmon
5 अप्रैल 2020, 12:24
2
आरक्षण और कमरे के बीच कोई उपयोगी संबंध नहीं है क्योंकि कमरे को उपलब्ध तारीख का कोई पता नहीं है और आरक्षण के लिए आवश्यक समय का कोई पता नहीं है। इसे देखते हुए ग्राहक_आईडी और तारीख पर आरक्षण में एक अनूठी कुंजी बनाएं।
 – 
P.Salmon
5 अप्रैल 2020, 12:35
1
"अब मैं एक बाधा पैदा करना चाहता हूं जो एक ऐसे ग्राहक को अनुमति नहीं देता है जिसने पहले से ही एक कमरा आरक्षित कर लिया है जो एक ही समय में उपलब्ध है!" - जैसे कोई कह रहा हो "ओह, हम बच्चों के साथ आते हैं, कृपया मुझे दो कमरे दें"? यह आवश्यकता कम से कम मेरे लिए बहुत खराब लगती है और वास्तविक दुनिया के परिदृश्यों को पूरी तरह से ध्यान में नहीं रखती है जहां आप एक ग्राहक के लिए कई कमरे आरक्षित करते हैं। सावधान रहें कि आप वास्तव में यह चाहते हैं - क्योंकि मैं कई कारणों के बारे में सोच सकता हूं कि मैंने एक ही समय में कई कमरे आरक्षित किए।
 – 
TomTom
5 अप्रैल 2020, 14:03
1
उसमें जोड़ने के लिए, आपके नाम आपके मॉडल को नहीं दर्शाते हैं। "कमरा" एक खराब नाम है क्योंकि यह किसी दिए गए (लेकिन बहुत त्रुटिपूर्ण) समय अवधि के लिए एक कमरे की उपलब्धता को दर्शाता है। ध्यान दें कि आपके विवरण में "अवधि" निहित है - क्या यह वास्तव में आपके सिस्टम की एक सीमा है? आपको वास्तव में अपने मॉडल के बारे में सोचना चाहिए, जैसा कि अन्य पहले ही कह चुके हैं।
 – 
SMor
5 अप्रैल 2020, 15:11

2 जवाब

अब मैं एक बाधा पैदा करना चाहता हूं जो एक ऐसे ग्राहक को अनुमति नहीं देता है जिसने पहले से ही एक कमरा आरक्षित करने के लिए एक कमरा आरक्षित किया है जो एक ही समय में उपलब्ध है।

मैं इसकी व्याख्या यह कहते हुए करता हूं कि एक ग्राहक प्रत्येक तिथि पर केवल एक कमरा आरक्षित कर सकता है। यदि ऐसा है, तो आप इसे reservation में (customer_id, date) पर एक अद्वितीय अनुक्रमणिका/बाधा के साथ कर सकते हैं:

create unique index unq_reservation_customer_date on reservation(customer_id, date);

यह गारंटी देता है कि एक दिया गया ग्राहक प्रत्येक तिथि पर केवल एक कमरा आरक्षित कर सकता है।

0
Gordon Linoff 5 अप्रैल 2020, 15:52
यह "0567 3563 05-10-2019" रिकॉर्ड को सम्मिलित करने से कैसे रोकता है?
 – 
Antonín Lejsek
5 अप्रैल 2020, 16:00
. . . यदि आपके पास तालिका में 0567/05-10-2019 के लिए पहले से ही एक पंक्ति है।
 – 
Gordon Linoff
5 अप्रैल 2020, 20:06

मैं वास्तविक बाधा उत्पन्न करने के दो तरीके देख सकता हूँ:

  1. आप दोनों तालिकाओं का भौतिक दृश्य बनाते हैं और इस दृश्य पर अद्वितीय अनुक्रमणिका जोड़ते हैं।
  2. आप आरक्षण तालिका में ROOM_DAY और ROOM_HOUR कॉलम जोड़ते हैं और डेटा अखंडता को लागू करने के लिए एक समग्र विदेशी कुंजी बाधा जोड़ते हैं:
ALTER TABLE RESERVATION WITH CHECK ADD CONSTRAINT FK_RESERVATION_ROOM 
FOREIGN KEY(ROOM_ID, ROOM_DAY, ROOM_HOUR)
REFERENCES ROOM (ROOM_ID, DAY, HOUR)

सावधान रहें आपको इसे भी सक्षम करना होगा। फिर आप आरक्षण तालिका पर अद्वितीय अनुक्रमणिका जोड़ सकते हैं।

0
Antonín Lejsek 6 अप्रैल 2020, 00:37