डेटाबेस की दुनिया में, कुछ चीजें हैं जिन पर सार्वभौमिक रूप से सहमति है। बढ़ी हुई रैम डीएमबीएस सिस्टम के लिए काफी हद तक फायदेमंद है। RAID पर डेटा और लॉग फ़ाइलों को फैलाने से प्रदर्शन में सुधार होता है।
नामकरण परंपराएं उन चीजों में से एक नहीं हैं।
यह आश्चर्यजनक रूप से ध्रुवीकरण करने वाला विषय है, जिसमें विभिन्न पद्धतियों के समर्थकों ने अपनी स्थिति में मजबूती से प्रवेश किया है। और उसी के बचाव में बहुत मुखर और भावुक।
प्रत्येक बिंदु के लिए एक उचित निष्कर्ष प्रस्तुत करने का प्रयास करते हुए, यह लेख कुछ विशिष्ट सम्मेलनों और दोनों पक्षों के तर्कों में तल्लीन होगा।
महान बहुलीकरण बहस
इसके मूल में, यह एक साधारण विषय है। उदाहरण के लिए, एक रिलेशनल डेटाबेस स्कीमा में ग्राहक जानकारी वाली तालिका को नाम देने का सही तरीका क्या है? क्या यह Customer है या Customer ?
दोनों पक्षों के तर्क लाजिमी हैं।
पहली नज़र में , बहुवचन में वस्तुओं के संग्रह के बारे में सोचना स्वाभाविक है। कई व्यक्तियों या कंपनियों का एक समूह होगा ग्राहक . इसलिए, एक टेबल (वस्तुओं का संग्रह होने के नाते) को बहुवचन में नामित किया जाना चाहिए। उस तालिका में एक एकल पंक्ति एकल ग्राहक होगी ।
आईएसओ/आईईसी नामकरण सिद्धांत, दिनांकित होने पर, बहुवचन तालिका नामों और एकवचन कॉलम नामों की अनुशंसा करते हैं।
अधिकांश SQL सर्वर सिस्टम तालिकाएँ बहुवचन नामों का उपयोग करती हैं (sysnotifications , सिसऑपरेटर्स ), लेकिन यह असंगत है। क्यों sysproxylogin और नहीं sysproxylogins ?
बहुवचन तालिका नामों के तर्कों में, एक तालिका में पंक्तियों को एक संपूर्ण के 'उदाहरण' के रूप में भी संदर्भित किया जाता है - एक संग्रह में आइटम के समान। ग्राहक पूरे सेट को परिभाषित करता है; एक अकेला ग्राहक ग्राहकों . का एक उदाहरण है ।
इसके विपरीत, एकवचन वस्तु नामों का उपयोग करने के कई कारण हैं।
जबकि कई आइटम हो सकते हैं (या ग्राहक ) किसी तालिका में, तालिका को ही एक इकाई माना जा सकता है। ग्राहकों का बॉक्स "ग्राहकों का बॉक्स" नहीं है, भले ही उसके अंदर बड़ी संख्या में ग्राहक हों। इसके अतिरिक्त, तालिका के अंदर केवल एक आइटम - या कोई नहीं - हो सकता है, जिससे "ग्राहक" एक मिथ्या नाम बन जाता है।
यदि आप शब्द प्रकार के आधार पर तालिका का नाम बदलना चुनते हैं, तो विसंगतियां जल्दी से उभर सकती हैं। जबकि कई शब्द सीधे होंगे (ग्राहक ग्राहक बन जाता है , उत्पाद उत्पाद बन जाता है ), दूसरे शब्द नहीं हो सकते हैं। इस मामले में, व्यक्ति लोग . बन सकते हैं या व्यक्तियों; एक विलक्षण मूस इसके बहुवचन रूप के समान दिखाई देगा, मूस . (यद्यपि आपको मूस की तालिका की आवश्यकता क्यों होगी?) एक सम्मेलन जैसे People.FirstName भ्रामक रूप से अस्पष्ट होने लगता है।
यदि कई भाषाएं शामिल हैं, तो स्थिति और भी खराब हो जाती है। क्योंकि शब्दों का बहुवचन कई तरीकों से भिन्न हो सकता है (ग्राहक, चूहे, मूस, बच्चे, संकट, पाठ्यक्रम, विमान), गैर-देशी वक्ताओं के लिए अतिरिक्त चुनौतियाँ हैं। एकवचन वस्तु नामों के साथ चिपके रहने से यह समस्या पूरी तरह से दूर हो जाती है।
केस कन्वेंशन प्रश्न
मामला सम्मेलनों के साथ बहुवचन के समान उत्साह नहीं है, लेकिन कई अलग-अलग विकल्पों के लिए तर्क दिए जाते हैं। उनमें शामिल हैं:
- पास्कल केस :प्रत्येक संयोजित शब्द के पहले अक्षर को बड़े अक्षरों में लिखा जाता है, जैसे:
CustomerOrder -
ऊंट केस :पहले शब्द का पहला अक्षर लोअरकेस है; बाद के सभी संयोजित शब्दों में एक कैपिटलाइज़्ड पहला अक्षर होता है, जैसे:
customerOrderपास्कल केस को कभी-कभी कैमल केस का उप-प्रकार माना जाता है, लेकिन माइक्रोसॉफ्ट आम तौर पर दोनों के बीच अंतर करता है।
तीन वर्णों से कम के शब्दों के लिए, केवल अपरकेस का उपयोग करने की अनुशंसा की जाती है, जैसा कि
UI. में है याIO। - अंडरस्कोर [“C” केस] :शब्दों को अंडरस्कोर से अलग किया जाता है, जैसा कि
Customer_Order. में होता है , याcustomer_Order- और भी फैसले!
जॉन्स हॉपकिन्स विश्वविद्यालय के शोधकर्ताओं ने प्रोग्रामिंग ऑब्जेक्ट नामों में अंडरस्कोर का उपयोग करने की दक्षता पर एक अध्ययन किया। उन्होंने पाया कि कैमल केस (या पास्कल केस) के उपयोग से टाइपिंग सटीकता और पहचान में सुधार हुआ है। सी प्रोग्रामिंग में अंडरस्कोर का व्यापक रूप से उपयोग किया गया था, लेकिन रुझान कैमल/पास्कल केस की ओर है, जिसमें हाल ही में माइक्रोसॉफ्ट और जावा-शैली की भाषाओं पर जोर दिया गया है।
अन्य विषयों की तरह, निम्नलिखित एक स्थापित सम्मेलन चयन . से अधिक महत्वपूर्ण है सम्मेलन के ही।
यहां एक अतिरिक्त विचार डेटाबेस की केस-संवेदनशीलता है। एसक्यूएल सर्वर संयोजन इस संवेदनशीलता को 'सीएस' (केस-संवेदी) या 'सीआई' (केस-असंवेदनशील) के साथ संयोजन नाम में निर्धारित करता है। उदाहरण के लिए:
SQL_Latin1_General_Cp437_CS_AS_KI_WI: Case Sensitive SQL_Latin1_General_Cp437_CI_AS_KI_WI: Case Insensitive
केस-संवेदी कॉलेशन में, Select * from myTable ऑब्जेक्ट के विरुद्ध विफल हो जाएगा MyTable . यह भ्रम को रोकने के लिए अंडरस्कोर को थोड़ा बेहतर बना सकता है, लेकिन Intellisense अधिकांश आधुनिक प्रोग्रामिंग वातावरण में टाइपिंग की गलतियों को खत्म करने में भी मदद करता है।
अन्य नामकरण सम्मेलन विचार
सिंगुलर बनाम प्लुरल डिबेट और ग्रेट केस क्वेश्चन वह हो सकता है जहां लड़ाई सबसे भयंकर हो, लेकिन नामकरण परंपरा पर विचार करते समय ध्यान में रखने के लिए कम से कम तीन और क्षेत्र हैं।
ऑब्जेक्ट नामों के रूप में किसी भी SQL सर्वर आरक्षित शब्दों का उपयोग करने से बचें। इसमें टेबल और कॉलम दोनों शामिल हैं। उदाहरण के लिए - उपयोगकर्ता , समय , और तारीख आरक्षित हैं। कॉलिंग एप्लिकेशन के आधार पर आरक्षित कीवर्ड को संदर्भ के लिए अतिरिक्त देखभाल की आवश्यकता हो सकती है (जैसे वर्ग कोष्ठक का उपयोग करना)। यह रिक्त स्थान पर भी लागू होता है। ऑब्जेक्ट नामों में रिक्त स्थान को संदर्भ के लिए उद्धरणों की आवश्यकता होती है।
यह एक और सिफारिश के साथ भी जुड़ा हुआ है - सटीक। System.CreateDate System.Date . से कहीं अधिक स्पष्ट है . एक अच्छी तरह से डिज़ाइन किया गया मॉडल दर्शक को अंतर्निहित वस्तुओं के उद्देश्य को तुरंत समझने की अनुमति देता है। जब किसी पहचानकर्ता को विदेशी कुंजी के रूप में संदर्भित किया जाना है, तो नाम में उदार रहें - Customer.CustomerID Customer.ID . के बजाय ।
तालिकाओं और दृश्यों के लिए उपसर्ग और प्रत्यय से बचें , जैसे tblTable . हंगेरियन नोटेशन (जिसका उद्देश्य हमेशा चर उपयोग की पहचान करना था) सामान्य SQL सर्वर नामकरण सम्मेलनों में फिसल गया, लेकिन यह व्यापक रूप से उपहासित है। ऑब्जेक्ट आइडेंटिफ़ायर को यह वर्णन करना चाहिए कि भीतर क्या है, न कि स्वयं ऑब्जेक्ट।
हालांकि, उपसर्ग SQL सर्वर समर्थित ऑब्जेक्ट में उपयोगी होते हैं , जैसा कि वे वस्तु की कार्यात्मक प्रकृति का वर्णन करते हैं।
SQL सर्वर ऑब्जेक्ट के लिए सामान्य रूप से स्वीकृत उपसर्ग निम्नलिखित हैं:
- IX:इंडेक्स
- पीके:प्राथमिक कुंजी
- FK:विदेशी कुंजी
- सीके:बाधा की जांच करें
- DF:डिफ़ॉल्ट
- UQ का उपयोग कभी-कभी अद्वितीय अनुक्रमणिका के लिए भी किया जाता है।
यह मॉडल ऊपर परिभाषित बिंदुओं को दिखाता है। इसे डेटा की प्रकृति के बारे में किसी स्पष्टीकरण की आवश्यकता नहीं है; एकवचन नामकरण परंपराओं का उपयोग किया जाता है, और स्पष्ट पहचानकर्ता मौजूद होते हैं।
अंत में, कन्वेंशन नामकरण बहस के प्रत्येक पक्ष के फायदे और नुकसान हैं। हालांकि, एक महत्वपूर्ण बिंदु यह है कि दोनों पक्ष इस पर सहमत हो सकते हैं:किए गए निर्णयों की परवाह किए बिना, चयनित सम्मेलन के अनुरूप होना चाहिए।
आप किन SQL नामकरण परंपराओं का उपयोग करते हैं और क्यों?
