Oracle में वस्तुओं का नामकरण। पक्ष से देखें

"मुख्य बात के बारे में पुराना गाना"

"डेटाबेस ऑब्जेक्ट्स के नामकरण के लिए मानक" और "कोड डिज़ाइन नियम" नए विषय नहीं हैं। एक तरीका या दूसरा, सभी विकास दल ऐसे मानकों और नियमों को विकसित करने या उधार लेने के सवाल पर आते हैं। यदि आप चाहें, तो आप नेटवर्क में इस विषय पर लेख और प्रस्तुतियां पा सकते हैं, साथ ही विभिन्न समझौतों के उदाहरण और टेम्पलेट। उनमें से कई निश्चित रूप से उपयोगी हैं, कुछ लगभग सही हैं, यदि एक छोटे से चेतावनी के लिए नहीं: वे डेवलपर्स द्वारा और डेवलपर्स के लिए लिखे गए हैं।

दुर्भाग्य से, मेरी व्यक्तिपरक वास्तविकता में, डेवलपर्स सिर्फ एक तरह के अमूर्त हैं। हैंडसेट के दूसरी तरफ ऐसे फैंटम, जिनसे हजारों किलोमीटर और 3 टाइम ज़ोन मुझे अलग करते हैं। उनके सामूहिक मस्तिष्क तक मेरी कोई सीधी पहुँच नहीं है। इस मस्तिष्क द्वारा उत्पन्न केवल छवियां ही उपलब्ध हैं - एक शोषित प्रणाली की वस्तुओं के रूप में।

सिद्धांत रूप में, "आवेदन" (एप्लिकेशन एडमिनिस्ट्रेटर / टेक्नोलॉजिस्ट) के पंजीकरण और नामकरण की इच्छाएं और डेवलपर 90 प्रतिशत मेल खाते हैं। लेकिन "पाठक" और "लेखक" की धारणा में अभी भी कुछ अंतर हैं, जिनके बारे में मैं बात करना चाहूंगा।

इस लेख का उद्देश्य: डेटाबेस ऑब्जेक्ट्स के नामकरण के लिए नियमों का एक सेट विकसित करना (I like the nameing Conventions - NC , Code Conventions के समान) सॉफ्टवेयर डेवलपर्स की एक टीम द्वारा Oracle DBMS पर आधारित सूचना प्रणाली के डिजाइन में उपयोग के लिए, निम्न आवश्यकताओं को पूरा करते हुए:

1. NC को यथासंभव पूर्ण होना चाहिए, अर्थात डेटाबेस ऑब्जेक्ट्स के सभी प्रकार के लिए नामकरण परंपराएं हैं
2. NC जितना संभव हो उतना छोटा होना चाहिए। आदर्श विकल्प: 1 ए 4 शीट।

क्यों Oracle डाटाबेस? वह मेरे करीब और प्रिय है। और सार्वभौमिकता के दावों के साथ अमरता को गले लगाने का प्रयास मेरे दांतों और दक्षताओं से परे है। इस विषय में, मैंने इस विषय पर बिल कूलम, स्टीवन फेउरस्टीन और टॉम कयटे द्वारा लेखों की सामग्रियों को संक्षेप में प्रस्तुत करने और विभिन्न सूचना प्रणालियों के डिजाइन, विकास और संचालन में मेरे मामूली अनुभव को संक्षेप में प्रस्तुत करने की कोशिश की।

जो नामकरण के लिए अलग-अलग दृष्टिकोणों के बारे में पढ़ने और इस या उस दृष्टिकोण के बचाव में तर्क के माध्यम से उतावले होने के लिए बहुत आलसी हैं, वे केवल लेख के माध्यम से अंत तक स्क्रॉल कर सकते हैं, जहां मैंने अपने खुद के "ओरेकल एनसी" पोस्टर के लिए एक लिंक दिया था। वहां आप विषय पर अन्य उपयोगी लिंक पा सकते हैं।

क्या आप अभी भी यहाँ हैं? क्या आप वापस पकड़ सकते हैं और स्क्रॉल करना शुरू नहीं किया है? बधाई हो, आपको एक विशेष बोनस मिलता है: आप "ओरेकल एनसी" पोस्टर को यहीं डाउनलोड कर सकते हैं, इस जगह को छोड़े बिना। तथ्य यह है कि मैंने पहले ही अपना लेख (हां) पढ़ा है और मैं आपको पहले से चेतावनी देता हूं: यह बोझिल है और इनसेट टेम्पलेट्स के साथ गर्भपात होता है जो पहली नज़र में अस्पष्ट हैं। एक शीट पर सभी नियमों और उदाहरणों को हाथ में लेते हुए, इसे समझना बहुत आसान होगा।

हर कोई जानता है कि टैंक में मुख्य चीज है, लेकिन हर कोई वापस नहीं पकड़ सकता है ...

ऐसा लगता है कि एक आईटी परियोजना के लिए नेकां के विकास का विचार सतह पर है। डिजाइन और विकास में नेकां की आवश्यकताओं का अनुपालन भी कोई देवता नहीं है। हालांकि, दूरसंचार कंपनियों के लिए बिलिंग सिस्टम बाजार में अग्रणी रूसी डेवलपर्स के समाधान के साथ मेरा अनुभव बताता है कि वस्तुओं के नामकरण और स्रोत कोड को डिजाइन करने की संस्कृति वास्तव में बहुत कम है। सिद्धांत रूप में, मैंने ड्यूटी के आधार पर अध्ययन किए गए सभी निर्णयों को चार समूहों में विभाजित किया जा सकता है:

1. नेकां के संकेतों की पूर्ण अनुपस्थिति (12 में से 2 उत्पाद)। यह एक बुरा सपना है। इस तरह की प्रणाली को संचालित करना चित्र के साथ एक पहेली को इकट्ठा करने जैसा है। जबरदस्त प्रयास की कीमत पर, केवल व्यक्तिगत धागे आपस में जुड़े और तर्क को गेंद से बाहर निकाला जा सकता है। और हर बार, एक नई समस्या के साथ, उलझन को फिर से सुलझाना पड़ता है।
2. एक परियोजना में विभिन्न एनसी का उपयोग करना (12 में से 3 उत्पाद)। यह तुरंत स्पष्ट है कि डेवलपर्स ने NC के बारे में सुना, अपनी शैली विकसित की और उसका पालन करना सीखा। समस्या यह है कि एक परियोजना के लिए बहुत सारे डेवलपर्स और शैलियाँ थीं। इस तरह के समाधान का संचालन इस तथ्य से बाधित है कि एक एकल मॉड्यूल का अध्ययन करने का अनुभव दूसरे में बेकार है। भाग को जानकर आप पूरे का एक विश्वसनीय विचार नहीं प्राप्त कर सकते हैं।
3. नेकां, जो शुरुआती संस्करणों में स्पष्ट रूप से दिखाई दे रहे थे, बैसाखी के ढेर के नीचे दबे हुए थे और एक शक्तिशाली दबाव पैच (12 में से 6 उत्पादों) के साथ धोया गया था। सबसे आम विकल्प। वही टैंक जिसमें वे खुद को संयमित नहीं कर सके।
4. सिस्टम के जीवन चक्र में सभी आवश्यकताओं और प्रतिबंधों के अनुपालन में स्पष्ट रूप से नियत एनसी। (12 में से 1 उत्पाद)। यहाँ वह एक लागू आदमी का सपना है ...

मैं पी.पी. के कारणों के विश्लेषण में तल्लीन नहीं करना चाहता। 1-3, मैं सिर्फ एक तथ्य बता रहा हूं। मैं चाहता हूं कि पैराग्राफ 4 के "सपने" की दिशा में एक कदम उठाने में मदद करना है। तो, चलिए शुरू करते हैं।

सामान्य सिफारिशें

ओरेकल डीबीएमएस के लिए विकसित करते समय याद रखें कि क्या याद रखना चाहिए और किसका पालन करना चाहिए:

1. याद रखें कि ओरेकल में ऑब्जेक्ट नाम 30 अक्षरों तक सीमित हैं। विस्तृत रूप से। अपने आप से मैं केवल एक इच्छा जोड़ सकता हूं। यदि आप अपने सिस्टम के साथ काम करने वाले लोगों को अनुप्रयोगों के माध्यम से नहीं चाहते हैं जो पागल होने के लिए "कोड संकेत" का समर्थन नहीं करते हैं, विवेकपूर्ण रहें - अपनी वस्तुओं के नामों को यथासंभव कम रखने का प्रयास करें।
2. याद रखें कि ऑब्जेक्ट नाम एक अंक से शुरू नहीं हो सकते हैं। कोई टिप्पणी नहीं।
3. वस्तुओं का नामकरण करते समय उसी भाषा का उपयोग करें। अंग्रेजी, अधिमानतः। लिप्यंतरण से बचें। मेरा विश्वास करो, ZDAZ नामक तालिका की तुलना में ORDERS नामक तालिका को बेहतर माना जाता है। और अधिक। बहुत बार वाणिज्यिक प्रणालियों में आपको संक्षिप्तीकरण से निपटना पड़ता है। उससे भी बचें। यूएसएसआर एसएसएसआर की तुलना में स्पष्ट है , और यूएसए किसी भी तरह एसएसएएच से स्पष्ट है।
4. हां, मैं लगभग भूल गया था। केवल लैटिन नामों में उपयोग करें! बेशक, यह बेवकूफों के लिए एक सिफारिश है, लेकिन मैं लगभग एक बार पागल हो गया था, SQLPLUS में एक मेज से लाने की कोशिश कर रहा था। और सभी क्योंकि बहुत अंत में रूसी लेआउट में एक प्रतीक "ई" था। पीएल / एसक्यूएल डेवलपर में, मुझे नाम पूरी तरह से लिखना नहीं था - कोड संकेत काम किया। मजेदार बात यह है कि तालिका एक महीने से अधिक समय तक इस रूप में रही है और मुझसे पहले किसी ने इसके बारे में शिकायत नहीं की थी।
5. अपने सिस्टम को डिजाइन करने की प्रक्रिया में (विषय क्षेत्र की जांच के तुरंत बाद), एक अलग फ़ाइल (तालिका - शब्दावली) में सभी पहचाने गए निकाय को फिर से लिखें। इंटरनेट पर चारों ओर अफवाह फैलाने के लिए बहुत आलसी मत बनो - आपकी अधिकांश संस्थाओं के लिए, लंबे समय से स्थापित और आमतौर पर स्वीकृत अंग्रेजी-भाषा के नाम हैं। उन्हें शब्दावली में ठीक करें। अन्य संस्थाओं के लिए, एक अच्छा अनुवाद करें। भावी संक्षिप्तीकरण के लिए भी यही करें। खैर, और फिर सबसे महत्वपूर्ण बात: हमेशा समान अर्थ तत्वों के लिए समान नामों का उपयोग करें।
6. Oracle आरक्षित शब्दों को नाम के रूप में उपयोग करने से बचें (सभी आरक्षित शब्दों की एक सूची को सिस्टम व्यू V $ RESERVED_START से चुनकर प्राप्त किया जा सकता है)। वैसे, ओरेकल के दिए गए प्रतिनिधित्व से कुछ शब्द और उपयोग करने की अनुमति नहीं देंगे। लेकिन ऐसे भी हैं जो सीधे उपयोग करने के लिए निषिद्ध नहीं हैं, लेकिन यह बेहतर है, आखिरकार, नहीं।
7. एक अंडरस्कोर के साथ ऑब्जेक्ट नामों में अलग टोकन। याद रखें कि ओरेकल संवेदनशील नहीं है, इसलिए MySuperPuperTableName जैसा आपका "ऊंट" शब्दकोश में पूरी तरह से अपठनीय MYSUPERPUPERTABLENAME में बदल जाएगा।
   
   
   थोड़ा सा विषयांतर

   ईमानदारी से, ओरेकल में आप किसी ऑब्जेक्ट के लिए केस-संवेदी नाम निर्दिष्ट कर सकते हैं। उदाहरण के लिए, इस तरह:
   
   create table "MyTable" (a number);
   
   संक्षेप में, इस तरह के विकृतियों से बचें।

ऑब्जेक्ट नामकरण नियम

टेबल

तालिकाओं के नामकरण के सवाल पर, मैं बिल कोलहम के दृष्टिकोण को लगभग पूरी तरह से साझा करता हूं। उसके द्वारा विकसित मानक संपूर्ण और व्यावहारिक रूप से आदर्श है, दोनों डेवलपर और "शोषक" के लिए। मैं यहां पूर्ण अनुवाद नहीं दूंगा, मैं केवल मूल बिंदुओं पर ध्यान केंद्रित करूंगा।

तो, कोलहम एक तालिका के नामकरण के निम्नलिखित सार्वभौमिक रूप प्रदान करता है (घुंघराले ब्रेसिज़ में अनिवार्य घटक शामिल हैं, और "सीधे" कोष्ठक वैकल्पिक वाले शामिल हैं):

 [_][_]{}[_] 

मॉड्यूल के तहत (कोलमा - सिस्टम समूह के संदर्भ में) का अर्थ है हमारे डेटाबेस के भीतर सबसिस्टम का नाम। आमतौर पर 2-4 वर्ण की कमी का उपयोग किया जाता है। उदाहरण के लिए, "टैरिफ" मॉड्यूल की तालिकाओं में उपसर्ग "TAR_" हो सकता है, और भुगतान मॉड्यूल की तालिकाएं "PAY_" उपसर्ग हो सकती हैं। मैं अपने दम पर जोड़ूंगा कि यदि विकास "विदेशी" योजना में किया जाता है, तो एक और दूसरे की वस्तुओं को अलग करने के लिए एक अतिरिक्त उपसर्ग जोड़ना उचित है। मैं आमतौर पर उपसर्ग के लिए अपने संगठन का संक्षिप्त नाम जोड़ता हूं। बेशक, यह वस्तुओं के नाम को लंबा करता है, लेकिन यह आपको प्रोजेक्ट ट्री में स्पष्ट रूप से "आपके" ऑब्जेक्ट का चयन करने की अनुमति देता है। यदि आप इस दृष्टिकोण से शर्मिंदा हैं, तो मॉड्यूल कोड ("स्थानीय डेवलपर्स" आमतौर पर X या XX - OEBS की विरासत को पसंद करते हैं) से पहले एकल वर्ण जोड़ना पर्याप्त है।

एक समूह का उपयोग समान उद्देश्यों के लिए किया जाता है: यह आपको समूह संस्थाओं के लिए अनुमति देता है जो तार्किक रूप से जुड़े हुए हैं (आमतौर पर एक समूह में 20 ऑब्जेक्ट तक)। यह 2-4 वर्णों की कमी भी है। सिस्टम और तार्किक समूहों का उपयोग करना न केवल वस्तुओं के पेड़ में समूहों को समूहित करने की अनुमति देता है, बल्कि एक पूरे के रूप में सिस्टम के विकास और रखरखाव को भी सरल करता है। वास्तव में, विशिष्ट वस्तुओं के नामों को याद रखने की आवश्यकता गायब हो जाती है, बस मॉड्यूल और तार्किक समूह के संक्षिप्ताक्षरों को याद रखें, और फिर कोड हिंट आपको आपकी ज़रूरत की वस्तु को आसानी से खोजने में मदद करेगा।

नाम के साथ , सब कुछ स्पष्ट है। यह इकाई का वास्तविक नाम है। बिल कोलहम ने एकवचन के उपयोग की सिफारिश की, लेकिन व्यक्तिगत रूप से मैं करीब हूं और बहुवचन (स्टीफन फुरस्टीन, हैलो!) से अधिक परिचित हूं। स्टीफन और बिल दोनों इकाई नामों में संक्षिप्त रूप से बचने की सलाह देते हैं। अपवाद 8 वर्णों से अधिक लंबे शब्द हैं।

एक शब्द में तालिका के उद्देश्य को व्यक्त करना हमेशा संभव नहीं होता है। इस मामले में, आदत से बाहर कुछ घरेलू डेवलपर्स नियम का उपयोग करते हैं, जिसे मैं खुद को "बिक्री रसीद नियम" कहता हूं, जब शब्द क्रम सामान्य से विशेष तक, सार से गुणों तक जाता है। यानी "टॉयलेट पेपर" के बजाय "टॉयलेट पेपर", "मसालेदार खीरे", और "टमाटर का पेस्ट"। दुर्भाग्य से, अंग्रेजी नामों में यह सबसे अधिक बार भयानक लगता है। YELLOW_SUBMARINE और SUBMARINE_YELLOW की तुलना करें। इस मामले में, मुझे किसी एकल टेम्पलेट पर भरोसा करने का कोई कारण नहीं दिखता है, लेकिन मैं उस आदेश का उपयोग करने की सलाह देता हूं जो किसी विशेष संदर्भ में अधिक उपयुक्त है।

एक भूमिका अनिवार्य रूप से सिस्टम में एक टेबल का उद्देश्य (गंतव्य का प्रकार) है। कोलहम ने लगभग दो दर्जन भूमिकाएं कीं, लेकिन मेरे स्वाद के लिए उनमें से कुछ बेमानी हैं। मैं केवल उन लोगों को दूंगा जो मैं उपयोग करता हूं:

• _AUD - टेबल्स जो बेस टेबल (जर्नल टेबल) की पंक्तियों में परिवर्तन के इतिहास को संग्रहीत करते हैं। मैं इस प्रकार की तालिका के लिए विभिन्न प्रणालियों में प्रत्यय _JN (लॉग) और _HIST से मिला। स्वयं ने प्रत्यय _AUDIT का उपयोग किया, अब _JN । और _AUD मुझे ट्रिगर के नाम से अधिक परिचित है।
• _LOG - एप्लिकेशन मैसेज कमिट टेबल (लॉग टेबल)
• _HIST - पुरालेख तालिका जिसमें पुराने डेटा अपलोड किए गए हैं । इस प्रकार की तालिका के लिए, मैं प्रत्यय _ARCH का उपयोग करता हूं
• _TYPE - संदर्भ तालिकाएँ, जिनमें से पंक्तियाँ अद्वितीय मानों की एक सूची हैं। घरेलू डेवलपर्स अक्सर निर्देशिका तालिकाओं के लिए _REF प्रत्यय का उपयोग करते हैं। मुझे _REF प्रत्यय भी पसंद है क्योंकि _TYPE शब्द डेवलपर्स के बीच बहुत लोकप्रिय है और अक्सर शीर्षक घटक का हिस्सा है।
• _GT - वैश्विक अस्थायी टेबल। स्टीफन फुरस्टीन ने उनके लिए प्रत्यय _TMP या _TEMP का उपयोग करने की सिफारिश की है, लेकिन यह मेरी राय में, हमारी मानसिकता का खंडन करता है। रूसी प्रोग्रामर का उपयोग किसी भी अस्थायी "कचरा" को चिह्नित करने के लिए _TEMP टोकन का उपयोग करने के लिए किया जाता है, इसलिए _GT और केवल GGT ।

एक अलग वर्ग में, कोलहम उन तालिकाओं की पहचान करता है जिनके माध्यम से कई-से-कई संबंध कार्यान्वित होते हैं। ऐसी तालिकाओं के लिए, वह निम्नलिखित नामकरण पैटर्न प्रदान करता है:

 [_]{/  1_/  2} 

अधिकांश परियोजनाओं में मैं आया था, डेवलपर्स ने ऐसी एसोसिएशन तालिकाओं के लिए "सार्थक" नामों का उपयोग किया था। मैं खुद टेम्पलेट का उपयोग करता हूं:

 [_][_]{  1_}{  2} 

इस मामले में तालिका कोड तालिका का संक्षिप्त नाम है जो लिंक में भाग लेता है (2-4 वर्ण)। उदाहरण के लिए, इस मानक में शिक्षक व्याख्यान ( शिक्षक ) में भाग लेने वाले एक छात्र के भंडारण ( छात्र ) को एक तालिका कहा जाता है। हां, पहली नज़र में यह प्रतिकारक दिखता है, लेकिन समय के साथ आप सुविधा को समझते हैं: पहली नज़र में आप तालिका को "गुच्छा" के रूप में वर्गीकृत करते हैं (पूर्ण नामों के बजाय कोड / संक्षिप्तिकरण के उपयोग के कारण), आप तुरंत देखते हैं कि कौन सी संस्थाएँ जुड़ी हुई हैं।

तालिका के कॉलम (कॉलम)

आइए नाम की कुल लंबाई पर प्रतिबंधों के साथ शुरू करें - 15 अक्षरों (बेहतर - कम) के भीतर रखने का प्रयास करें। विदेशी कुंजी के साथ बाधाओं, अनुक्रमित और स्तंभों के बाद के नामकरण के लिए आपको ऊपरी बाधा के लिए एक मार्जिन की आवश्यकता होगी।
मेरी परियोजनाओं में, मैं निम्नलिखित टेम्पलेट का उपयोग करता हूं:

 [ _]{ }[_] 

तालिका कोड उस तालिका का संक्षिप्त नाम है जिसमें स्तंभ (2-4 वर्ण) होता है। हालाँकि मैंने यह उपसर्ग वैकल्पिक निर्दिष्ट किया है, मैं इसे लगभग सभी स्तंभों के लिए उपयोग करता हूँ। अपवाद "सेवा" कॉलम है जो किसी भी तालिका के सार रिकॉर्ड के कुछ गुणों के मूल्य को संग्रहीत करता है, न कि किसी विशेष वस्तु के गुण (उदाहरण के लिए, UPDATE_DATE , UPDATE_BY , आदि)।

कॉलम का नाम अपने लिए बोलता है। अलग से, मैं केवल विदेशी कुंजी के नाम के गठन के नियम के बारे में कहना चाहता हूं - इसमें चाइल्ड टेबल के कोड और माता-पिता की प्राथमिक कुंजी का पूरा नाम शामिल है।

भूमिका - वैकल्पिक प्रत्यय। कृपया ध्यान दें कि यह एक स्तंभ मान प्रकार है, इस स्तंभ के लिए डेटा प्रकार कोड नहीं! अक्सर मैं निम्नलिखित भूमिकाओं (मूल्य प्रकार) का उपयोग करता हूं:

• _ID - मुख्य वस्तु पहचानकर्ता से पूछताछ करें
• _NUM - एक स्ट्रिंग फ़ील्ड जिसमें कुछ संख्या होती है।
• _CODE - इकाई की स्ट्रिंग कुंजी (संदर्भ तालिकाओं के लिए अद्वितीय)।
• _DESC - इकाई का सारांश
• _YN - प्रकार CHAR (1), मान Y (तों) या N (o) लेते हुए

कई टेम्पलेट पर विचार करते हैं (और, विशेष रूप से, तालिका कोड के रूप में उपसर्ग) निरर्थक। हालांकि, विभिन्न दृष्टिकोणों की तुलना करने में सक्षम होने के नाते, मैंने इसे अपने लिए चुना। मैं अपने कारण बताऊंगा:

1. अधिक पठनीय प्रश्न। एक उपसर्ग वाले कॉलम के द्वारा, आप तुरंत समझ जाते हैं कि हम किस तालिका के बारे में बात कर रहे हैं। यह कोई रहस्य नहीं है कि अक्सर डेवलपर्स कॉलम को अर्हता प्राप्त करने के लिए बहुत आलसी होते हैं, इसलिए एक उपसर्ग वाले कॉलम का नाम "विदेशी" प्रश्नों के साथ काम करना आसान बनाता है।
2. अपवादों (त्रुटियों) के निदान की सुविधा है। बेशक, उनमें से ज्यादातर बाधाओं का उल्लेख करते हैं, विशिष्ट कॉलम नहीं, लेकिन बाधा का नाम लगभग हमेशा स्तंभ नाम पर आधारित होता है।
3. सिस्टम डिक्शनरी से आरक्षित शब्दों के साथ मेल खाने वाले कॉलम नाम की संभावना कम हो जाती है। यह NAME, ID, COMMENT और DATE जैसे सामान्य नामों के लिए विशेष रूप से सत्य है। नतीजतन, डेवलपर को नाम में अन्य अनावश्यक चरित्र संयोजनों को जोड़ने की आवश्यकता से मुक्त किया जाता है।
4. हमारी कंपनी में, यह पता चला कि उपयोग किए जाने वाले अधिकांश क्लाइंट सॉफ़्टवेयर ओरेकल फॉर्म्स के आधार पर विकसित किए गए थे, जहां किसी भी क्षेत्र के लिए, एफ 1 बटन का उपयोग करके, आप स्रोत कॉलम का नाम देख सकते हैं। डेटाबेस में किसी ऑब्जेक्ट के साथ एक फॉर्म पर किसी ऑब्जेक्ट को तुरंत संबद्ध करने की क्षमता सिस्टम के साथ और आगे के संचालन में प्रारंभिक परिचित में बहुत सहायक है।

प्रतिबंध

कोलहम ने तालिका के पूर्ण नाम के रूप में उपसर्ग का उपयोग करते हुए नामकरण की बाधाओं का सुझाव दिया है, जिस पर यह प्रतिबंध लागू होता है। मैं इस नामकरण को अनुचित अपशिष्ट मानता हूं, विशेष रूप से प्रति नाम लंबाई 30 वर्णों की सामान्य सीमा दी गई है। इसलिए, मैं कोशिश करता हूं, जहां पूर्ण नाम के बजाय तालिका के कोड का उपयोग करना संभव है। इस प्रकार, हमें प्राप्त होने वाली प्राथमिक कुंजी के लिए:

 [_][_]{ }{_PK} 

इसके बाद, मॉड्यूल और समूह प्रतिबंध उपसर्गों को उस तालिका से विरासत में मिला है जिसके साथ वे जुड़े हुए हैं। यह बड़ी प्रणालियों में नामों के निर्माण में विशिष्टता के उल्लंघन से बचता है, और यह मॉड्यूल पर समूह प्रतिबंधों के लिए भी सुविधाजनक है।

एक स्तंभ पर निर्मित एक अद्वितीय कुंजी के लिए:

 [_][_]{ }{_UK} 

मैं आपको याद दिलाता हूं कि हमारे लिए कॉलम टेम्पलेट में टेबल कोड शामिल है । इस प्रकार, UTL_PARAMS_REF तालिका के PRM_CODE कॉलम के लिए , अद्वितीय कुंजी को UTL_PRM_CODE_UK कहा जाएगा

कई स्तंभों पर निर्मित एक अद्वितीय कुंजी के लिए:

 [_][_]{ _}{CMP_UK}[_#] 

COMP - इस मामले में मतलब है COMPOSITE (समग्र कुंजी चिह्न), # (क्रम संख्या) का उपयोग किया जाता है यदि कई अद्वितीय समग्र कुंजियाँ हैं (ईमानदार होने के लिए, मैं इस मामले के लिए एक उदाहरण के साथ नहीं आ सकता)।

एक कॉलम के आधार पर विदेशी कुंजी:

 [_][_]{ }{_FK} 

चूंकि विदेशी कुंजी कॉलम का पूरा नाम बच्चे और माता-पिता की तालिकाओं का कोड होता है, UTL_PARAM_VALUES तालिका के PVL_PRM_ID कॉलम के लिए विदेशी कुंजी को UTL_PVL_PRM_ID_FK कहा जाएगा ( UTL_PARAMS_REF तालिका के PRM_ID कॉलम को संदर्भित करता है)

कई स्तंभों पर निर्मित एक विदेशी कुंजी:

 [_][_]{ _}{COMP_FK}[_#] 

कॉलम स्तर की बाधा:

 [_][_]{ }{_CK} 

तालिका स्तर सीमा:

 [_][_]{ _}{COMP_CK}[_#] 

इंटरनेट पर, मुझे अक्सर नॉट नाउल टाइप के अवरोधों के नाम की आवश्यकता के बारे में गर्म विचार-विमर्श मिला। हां, मैं सहमत हूं, आलसी, लेकिन अगर आप अवधारणा का सख्ती से पालन करते हैं, तो:

 [_][_]{ }{_NN} 

सूचकांक

मैं आमतौर पर अनुक्रमित को तीन श्रेणियों में विभाजित करता हूं:

1. कुंजी-आधारित अनुक्रमणिका (प्राथमिक और अद्वितीय)
2. सिंगल कॉलम इंडेक्स
3. यौगिक (कई स्तंभों पर आधारित)

कुंजी-आधारित अनुक्रमित (प्राथमिक और अद्वितीय) को उनके संबंधित प्रतिबंधों के रूप में उसी तरह नामित किया जाता है:

 [_][_]{ }{_PK} [_][_]{ }{_UK} [_][_]{ _}{CMP_UK}[_#] 

एकल स्तंभ पर आधारित संकेत:

 [_][_]{ }[_]{_IDX} 

इस टेम्पलेट में भूमिका एक सूचकांक प्रकार संशोधक को संदर्भित करता है। Colem निम्नलिखित संशोधक का उपयोग करने की सिफारिश करता है:

• एल - स्थानीय विभाजन सूचकांक
• जी - विभाजन तालिका पर वैश्विक सूचकांक
• बी - बिटमैप इंडेक्स
• एफ - फंक्शन आधारित सूचकांक
• सी - संपीड़ित सूचकांक (संपीड़ित)
• आर - रिवर्स की इंडेक्स (कुंजी के रिवर्स ऑर्डर के साथ इंडेक्स)
• यू - अद्वितीय सूचकांक

कई स्तंभों पर आधारित सूचकांक। कोलहम निम्नलिखित रूप की सिफारिश करते हैं:

 [_][_]{ }{_COMP}[_]{_IDX}[#] 

मैं Colem पैटर्न को एक विशेष मामला मानता हूं और हमेशा सभी स्तंभों को सूचीबद्ध करने का प्रयास करता हूं (यदि यह लंबाई सीमा का उल्लंघन नहीं करता है)

 [_][_]{ _}{ }[_]{_IDX} 

मैं प्रतिबंधों के लिए COMP संशोधक तक सीमित क्यों हूं, लेकिन इसे अनुक्रमित करने के लिए उपयोग नहीं करने का प्रयास करता हूं? बात यह है कि समग्र बाधाएं नियम के बजाय अपवाद हैं। आमतौर पर उनमें से बहुत सारे नहीं होते हैं, और उनके उल्लंघन के बारे में एक त्रुटि वाला संदेश बहुत बार नहीं मिलता है। मिश्रित सूचकांक एक और मामला है। सबसे पहले, उनमें से बहुत सारे हैं। दूसरे, अक्सर एक से अधिक टेबल होते हैं। और तीसरा, एप्लिकेशन के डेवलपर और व्यवस्थापक लगातार उनके साथ काम करते हैं, क्वेरी योजनाओं की जांच करते हैं।

ट्रिगर्स

इस लेख में, मैं केवल डीएमएल ट्रिगर पर विचार करता हूं, क्योंकि मेरा मानना ​​है कि अन्य सभी प्रकार डीबीए की जिम्मेदारी में अधिक हैं, न कि डेवलपर। मैं निम्नलिखित नियमों द्वारा ट्रिगर कहता हूं:

 [_][_]{ }[_/]_{B|A|C (I|U|D)[S]}[_#] 

जहां संक्षिप्ताक्षर B , A , C ( BEFORE , AFTER , COMPOUND ), ट्रिगर का "क्षण" निर्धारित करते हैं; I , U , D ( INSERT , UPDATE , DELETE ) - प्रतिक्रिया घटना; एस (स्थिति) - ऑपरेशन के "स्तर" का निर्धारण।

अपनी परियोजनाओं में, मैं दो "टाइप किए गए" ट्रिगर (भूमिकाएं) को अलग करता हूं:

• AUDIT - ट्रिगर करता है जो पत्रिका में मुख्य तालिका में परिवर्तन करता है (उदाहरण के लिए, UTL_PRM_AUDIT_AIUD )
• INIT - "इनिशियलाइज़िंग" सरोगेट कुंजी बनाने और कॉलम के लिए डिफ़ॉल्ट मान भरने के लिए जिम्मेदार ट्रिगर करता है (उदाहरण के लिए, UTL_PRM_INIT_BI )

की प्रस्तुति

नामकरण के नियमों के नाम तालिकाओं के नामकरण के नियमों से अलग नहीं हैं। केवल इच्छा का नाम एक संकेत में शामिल करना है कि यह ऑब्जेक्ट सिर्फ एक प्रतिनिधित्व है। यहां के दृष्टिकोण भिन्न हो सकते हैं। मुझे यह लक्षण उपसर्ग नाम के रूप में मिला। उदाहरण के लिए, V_ या यहां तक ​​कि V $ , ओरेकल सिस्टम के विचारों की तरह। व्यक्तिगत रूप से, मैं प्रत्यय का उपयोग करता हूं:

• $ V - नियमित विचारों के लिए
• $ एमवी - भौतिक के लिए

लेकिन मैं आपको सलाह नहीं दूंगा। एक विभाजक के रूप में डॉलर का संकेत आदत का विषय है। यह मेरी आंखों के लिए एक "लंगर" है, जो मुझे एक दृश्य से एक तालिका को भेद करने की अनुमति देता है। मैं इन दृष्टिकोणों पर एक उद्देश्य नहीं देख सकता; इसलिए, मेरे पास "अंडरस्कोर" संकेत के खिलाफ कुछ भी नहीं है, जैसे कि फर्सस्टैन (प्रत्यय _वी और _एमडब्ल्यू )।

दृश्यों

मैं प्रत्यय _SEQ द्वारा अन्य वस्तुओं के अनुक्रमों को अलग करता हूं और निम्नलिखित नियम द्वारा उनका नामकरण करने की सलाह देता हूं:

 [_][_]{  |    | }{_SEQ} 

टेबल कोड ( तालिका का संक्षिप्त नाम 2-4 अक्षर है) का उपयोग उन अनुक्रमों के लिए किया जाता है जो तालिका की सरोगेट प्राथमिक कुंजी उत्पन्न करने के लिए सेवा करते हैं।

स्तंभ का नाम (और यहां, मुझे याद है, जिसमें तालिका का कोड शामिल है) का उपयोग स्तंभ के मूल्य को उत्पन्न करने के लिए किया जाता है जो प्राथमिक कुंजी में शामिल नहीं है। वास्तव में, यह एक पतित मामला है जिसका मैं वास्तव में उपयोग नहीं करता हूं। यदि अनुक्रम का उपयोग मुख्य कुंजी मान उत्पन्न करने के लिए नहीं किया जाता है - नाम में मैं इस अनुक्रम के उद्देश्य को प्रतिबिंबित करने का प्रयास करता हूं।

उदाहरण के लिए, मैं INTERNET_LOGINS तालिका ILG_SEQ की प्राथमिक कुंजी जनरेट करने के लिए अनुक्रम को कॉल करूंगा , और एक विशिष्ट इंटरनेट खाते के लिए लॉगिन बनाने का क्रम LOGIN_SEQ है ।

समानार्थी

समानार्थी शब्द उसी तरह संदर्भित किए जाते हैं जिस तरह से वे वस्तुओं को संदर्भित करते हैं।

प्रकार

प्रकार से, मेरे पास निश्चित रूप से गठित राय नहीं है। इन वस्तुओं के नामकरण के लिए मुझे अलग-अलग दृष्टिकोण मिले, लेकिन मैं पूरी तरह से यह तय नहीं कर सका कि कौन सा दृष्टिकोण मेरे करीब है। मैं यहां उन लोगों का वर्णन करूंगा जो मुझ पर नकारात्मक प्रतिक्रिया नहीं देते हैं:

  [_][_]{}[_ ]T 

यह टेम्पलेट Coleam द्वारा अनुशंसित है। प्रकार संग्रह का संकेत प्रतीक टी द्वारा पहचाना जाता है । इस प्रकार, एकल वस्तु के प्रकार में हमेशा प्रत्यय _T होता है , संग्रह प्रकार _TT होता है । उदाहरण के लिए, UTL_PARAMETER_T , UTL_PARAMETER_TT ।

 [_][_]{}[S]_TYP 

यहाँ S बहुवचन को दर्शाता है, और प्रत्यय TYP एक प्रकार के रूप में डेटाबेस ऑब्जेक्ट को योग्य बनाता है । उदाहरण के लिए, UTL_PARAMETER_TYP , UTL_PARAMETERS_TYP । मुझे यह दृष्टिकोण कम से कम पसंद है, क्योंकि संग्रह का संकेत हाइलाइट नहीं किया गया है और आंख इसे नहीं पकड़ती है।

 [_][_]{}_{OBJ | TAB} 

इस अंकन में, यदि डेटाबेस ऑब्जेक्ट का नाम OBJ या TAB में समाप्त होता है, तो ऑब्जेक्ट एक प्रकार है ( TAB एक संग्रह है, OBJ एक एकल ऑब्जेक्ट है)। उदाहरण के लिए, UTL_PARAMETER_OBJ , UTL_PARAMETERS_TAB

सॉफ्टवेयर मॉड्यूल

कार्यक्रम मॉड्यूल के कोड को डिजाइन करने के नियम मैं एक अलग लेख को एकल करना चाहूंगा। यहाँ Coleam द्वारा सुझाया गया एक टेम्पलेट है। प्रक्रिया पैकेज के लिए, बिल निम्नलिखित नियम का उपयोग करता है:

 [_][_]{/}[_. ][_PKG] 

NC Coleam के संदर्भ में, एक कार्यात्मक संशोधक (मेरे लिए उपसमूह शब्द अधिक समझ में आता है) का उपयोग कुछ कार्यों को फिर से भरने के लिए एक अलग पैकेज में अलग करने के लिए किया जाता है। मान लीजिए कि यह तार्किक समूह का एक अतिरिक्त स्तर है। उदाहरण के लिए, UTIL पैकेज में संख्याओं और तारों के साथ काम करने के लिए कार्य शामिल थे। इसे दो में विभाजित किया गया था: UTIL_NUMBER और UTIL_STRING ।

पीएल / एसक्यूएल में विकसित करते समय, एक विशेषज्ञ लगातार अन्य पैकेजों के कार्यों और प्रक्रियाओं के साथ काम करता है। ताकि कोड भारी न दिखे, मैं कोशिश करता हूं कि पैकेजों के नाम पर अनावश्यक लांघनों से बचूं। इसलिए, मैं केवल उन मामलों में प्रत्यय _PKG का उपयोग करता हूं जहां पैकेज का नाम योजना के किसी अन्य ऑब्जेक्ट के नाम के साथ मेल खा सकता है।

व्यक्तिगत प्रक्रियाओं और कार्यों के लिए, कोलहम निम्नलिखित टेम्पलेट की सिफारिश करते हैं:

 [_]{/} 

क्रिया से अभिप्राय क्रिया से होता है ( GET , SET , ASSIGN , RUN ), लक्ष्य द्वारा किया जाना चाहिए। अपने हिस्से के लिए, मैं विकास के दौरान पैकेजों के बाहर की प्रक्रियाओं और कार्यों का उपयोग नहीं करने का प्रयास करता हूं। इसके अलावा, समान कार्य अक्सर उन वस्तुओं द्वारा समूहीकृत होते हैं जिनके साथ वे काम करते हैं, इसलिए मैं आमतौर पर एक टेम्पलेट का उपयोग करता हूं

 {}[_] 

इस प्रकार, कोड संकेत प्रक्रियाओं को वस्तुओं में जोड़ता है : PARAM_GET , PARAM_SET , PARAM_CHECK , आदि।

निष्कर्ष

जैसा कि वादा किया गया था, मैं अपने खुद के "ओरेकल एनसी" पोस्टर के लिए एक लिंक उद्धृत करता हूं।
किसी भी तरह से मैं अपने नियमों और मानकों को किसी पर नहीं थोपता और उनके इस्तेमाल पर जोर नहीं देता। मैं सिर्फ नेकां की उपस्थिति और टीम में इसकी आवश्यकताओं के पालन को एक अच्छी शैली मानता हूं - डेवलपर की "विनम्रता" जो बाद में सिस्टम के साथ काम करेगा।
आपकी परियोजनाओं के साथ शुभकामनाएँ।

पीएस एक चौकस पाठक ने निश्चित रूप से मेरे छोटे धोखे को देखा। लेख का पहला लक्ष्य कभी हासिल नहीं किया गया था: सभी प्रकार के ओरेकल डीबीएमएस ऑब्जेक्ट्स लेख में वर्णित नहीं हैं और एनसी पोस्टर में मौजूद हैं। खैर, आपके पास इस दोष को ठीक करने का मौका है। आप NC पोस्टर के "स्रोत" को डाउनलोड कर सकते हैं और अपने लक्ष्यों और उद्देश्यों को पूरा करने के लिए इसे संपादित कर सकते हैं।

निम्नलिखित स्रोत का उपयोग लेख में किया गया है:

1. स्टीवन फेउरस्टीन का ब्लॉग और उसके नामकरण कन्वेंशन और कोड मानक
2. ओरेकल नामकरण मानक बिल कुलम
3. टॉम Kyte ब्लॉग टॉम पूछें ...
   फोरम सामग्री SQL.RU