ओटी:आईएमएचओ काफी कुछ चीजें हैं जो SQL सर्वर समर्थन नहीं करता है, लेकिन एक उद्यम वातावरण में समझ में आता है:
- आस्थगित प्रतिबंध जैसा कि यहां बताया गया है
- MARS:बस आपको पूरी तरह से प्राकृतिक चीज़ के लिए एक विकल्प सेट करने की आवश्यकता क्यों है?
- कैस्केड डिलीट बाधाएं:एसक्यूएल सर्वर किसी दिए गए कैस्केड डिलीट बाधा के लिए केवल एक एकल कैस्केडेशन पथ की अनुमति देता है। दोबारा, मुझे कोई कारण नहीं दिख रहा है कि इसे कई संभावित पथों के माध्यम से हटाने पर कैस्केड करने की अनुमति क्यों नहीं दी जानी चाहिए:अंत में, जब इसे वास्तव में निष्पादित किया जाता है, तो वास्तव में केवल एक ही पथ का उपयोग किया जाएगा, तो क्यों क्या यह प्रतिबंध है?
- एकल ADO.NET कनेक्शन पर समानांतर लेनदेन की रोकथाम।
- एक कनेक्शन पर निष्पादित प्रत्येक आदेश को मजबूर करना जिसमें इस लेनदेन के भीतर लेनदेन निष्पादित किया जाना है।
- एक अद्वितीय सूचकांक बनाते समय, NULL को वास्तविक मान के रूप में माना जाता है, और सूचकांक में केवल एक बार प्रदर्शित होने की अनुमति दी जाती है। हालांकि, "अज्ञात मान" के रूप में एनयूएलएल की एसक्यूएल की धारणा इंगित करेगी कि इंडेक्स बनाते समय NULL मानों को पूरी तरह से अनदेखा कर दिया जाएगा...
ये सभी छोटी चीजें कई संदर्भात्मक अखंडता और लेन-देन की विशेषताएं बनाती हैं जिनकी आप एक पूर्ण आकार के RDBMS से SQL सर्वर में लगभग बेकार होने की उम्मीद करेंगे। उदाहरण के लिए, चूंकि आस्थगित बाधाओं का समर्थन नहीं किया जाता है, इसलिए बाहरी रूप से सुसंगत इकाई कार्य के रूप में "लेन-देन" की धारणा को आंशिक रूप से नकार दिया जाता है, एकमात्र व्यवहार्य समाधान - कुछ गंदे कामकाज को छोड़कर - संदर्भित अखंडता बाधाओं को बिल्कुल भी परिभाषित नहीं करना है। मुझे उम्मीद है, एक लेन-देन का स्वाभाविक व्यवहार यह होगा कि आप इसके अंदर काम कर सकते हैं और संचालन के क्रम में आप की तरह काम कर सकते हैं, और सिस्टम यह सुनिश्चित करेगा कि जब आप इसे करते हैं तो यह सुसंगत है। इसी तरह की समस्याएं प्रतिबंध से उत्पन्न होती हैं, ON DELETE CASCADE के साथ एक संदर्भात्मक अखंडता बाधा को केवल इस तरह से परिभाषित किया जा सकता है कि केवल एक ही बाधा किसी वस्तु के कैस्केड विलोपन का कारण बन सकती है। यह वास्तव में अधिकांश वास्तविक दुनिया के परिदृश्यों में फिट नहीं बैठता है।
