संग्रहीत प्रक्रियाओं के लिए आपका नामकरण सम्मेलन क्या है? [बन्द है]

Question

मैंने संग्रहीत प्रक्रियाओं के नामकरण के लिए विभिन्न नियम देखे हैं।

कुछ लोग usp_ के साथ स्पार्क नाम को उपसर्ग करते हैं, दूसरों को ऐप के नाम के साथ एक संक्षिप्त नाम और एक मालिक के नाम के साथ अभी भी अन्य। आपको SQL सर्वर में sp_ का उपयोग नहीं करना चाहिए जब तक कि आप वास्तव में इसका अर्थ नहीं करते हैं।

कुछ लोग क्रिया नाम की शुरुआत क्रिया के साथ करते हैं (प्राप्त करें, जोड़ें, सहेजें, निकालें)। अन्य लोग इकाई के नाम पर जोर देते हैं।

सैकड़ों स्प्रोक्स वाले डेटाबेस पर, जब आप पहले से मौजूद हैं, तो आपको लगता है कि चारों ओर स्क्रॉल करना और एक उपयुक्त स्पोक ढूंढना बहुत कठिन हो सकता है। नामकरण सम्मेलनों एक स्थान को आसान बना सकते हैं।

क्या आप एक नामकरण सम्मेलन का उपयोग करते हैं? कृपया इसका वर्णन करें, और समझाएं कि आप इसे अन्य विकल्पों पर क्यों पसंद करते हैं।

उत्तरों का सारांश:

• हर कोई नामकरण की निरंतरता की वकालत करता है, कि सभी के लिए समान नामकरण सम्मेलन का उपयोग करना अधिक महत्वपूर्ण हो सकता है, जिसमें से किसी एक का उपयोग किया जाता है।
• उपसर्ग: जबकि बहुत सारे लोग usp_ या कुछ समान (लेकिन शायद ही कभी sp_) का उपयोग करते हैं, कई अन्य डेटाबेस या ऐप नाम का उपयोग करते हैं। एक चतुर डीबीए सामान्य सीआरयूडी स्प्रोक्स को रिपोर्टिंग या कार्यों के लिए इस्तेमाल करने के लिए सामान्य, आरटीटी और टीएससी का उपयोग करता है।
• क्रिया + संज्ञा संज्ञा + क्रिया की तुलना में थोड़ी अधिक लोकप्रिय लगती है। कुछ लोग क्रियाओं के लिए SQL कीवर्ड (सेलेक्ट, इंसर्ट, अपडेट, डिलीट) का उपयोग करते हैं, जबकि अन्य गैर-SQL क्रिया (या उनके लिए संक्षिप्त रूप) का उपयोग करते हैं जैसे गेट और ऐड। कुछ एकल और बहुवचन संज्ञाओं के बीच अंतर को इंगित करने के लिए कि क्या एक या कई रिकॉर्ड को पुनर्प्राप्त किया जा रहा है।
• एक अतिरिक्त वाक्यांश अंत में सुझाया गया है, जहां उपयुक्त है। GetCustomerById, GetCustomerBySaleDate।
• कुछ लोग नाम सेगमेंट के बीच अंडरस्कोर का उपयोग करते हैं, और कुछ अंडरस्कोर से बचते हैं। app_ Get_Customer बनाम appGetCustomer - मुझे लगता है कि यह पठनीयता की बात है।
• Sprocs के बड़े संग्रह को Oracle पैकेज या मैनेजमेंट स्टूडियो (SQL सर्वर) समाधान और प्रोजेक्ट या SQL सर्वर स्कीमा में अलग किया जा सकता है।
• अपमानजनक संक्षिप्तताओं से बचना चाहिए।

मैंने जो उत्तर दिया, उसे क्यों चुना: SO बहुत सारी अच्छी प्रतिक्रियाएँ हैं। आप सभी को धन्यवाद! जैसा कि आप देख सकते हैं, बस एक को चुनना बहुत कठिन होगा। जिसे मैंने चुना वह मेरे साथ प्रतिध्वनित हुआ। मैंने उसी पथ का अनुसरण किया है जिसका वह वर्णन करता है - क्रिया + संज्ञा का उपयोग करने की कोशिश करना और फिर ग्राहक पर लागू होने वाले सभी स्पार्क्स को खोजने में सक्षम नहीं होना।

मौजूदा स्पोक का पता लगाने में सक्षम होने या यह निर्धारित करने के लिए कि कोई मौजूद है, बहुत महत्वपूर्ण है। यदि कोई व्यक्ति अनजाने में किसी अन्य नाम के साथ एक नकली स्प्रो बनाता है तो गंभीर समस्याएं उत्पन्न हो सकती हैं।

चूंकि मैं आम तौर पर सैकड़ों स्प्रोक्स के साथ बहुत बड़े ऐप पर काम करता हूं, इसलिए मुझे सबसे आसान नामकरण विधि के लिए प्राथमिकता है। एक छोटे ऐप के लिए, मैं वर्ब + संज्ञा की वकालत कर सकता हूं, क्योंकि यह विधि नामों के लिए सामान्य कोडिंग कन्वेंशन का अनुसरण करता है।

वह बहुत उपयोगी usp_ के बजाय ऐप नाम के साथ उपसर्ग की वकालत भी करता है। जैसा कि कई लोगों ने बताया, कभी-कभी डेटाबेस में कई ऐप के लिए स्प्रोक्स होते हैं। तो, ऐप नाम के साथ प्रीफ़िक्सिंग करने से स्प्रोक्स को अलग करने में मदद मिलती है और डीबीए और अन्य लोगों को यह निर्धारित करने में मदद मिलती है कि स्पोक का उपयोग किस ऐप के लिए किया जाता है।

Comments

Usp किस लिए खड़ा है?

— मिडट

मेरा मानना ​​है कि usp "उपयोगकर्ता प्रक्रिया" के लिए छोटा है। जो इसे "sp_" उपसर्ग प्रणाली प्रक्रियाओं से अलग करता है। यह एक महत्वपूर्ण अंतर है, जैसा कि आप उत्तरों में पढ़ सकते हैं।

— DOK 5'10

धन्यवाद डॉक। ग्राज़ी मिल

— मिडहैट

sqlblog.com/blogs/aaron_bertrand/archive/2008/10/30/… (भी देखें: stackoverflow.com/questions/871612/… )

— mg1075

मैं इसे सिर्फ इसलिए बंद कर रहा हूं क्योंकि यह बंद है, उम्मीद है कि शक्तियों को दिखाने के लिए कि इस तरह के प्रश्न समुदाय के लिए उपयोगी हैं।

— tsilb

Answer 1

अपने अंतिम प्रोजेक्ट के लिए मैंने usp_ [क्रिया] [ऑब्जेक्ट] [प्रक्रिया] का उपयोग किया है, उदाहरण के लिए, usp_AddProduct या usp_GetProductList, usp_GetProductDetail। हालाँकि अब डेटाबेस 700 प्रक्रियाओं के साथ है, एक विशिष्ट वस्तु पर सभी प्रक्रियाओं को खोजना बहुत कठिन हो जाता है। उदाहरण के लिए मुझे अब उत्पाद जोड़ने के लिए 50 विषम जोड़ें और गेट के लिए 50 विषम आदि को खोजना होगा।

इस वजह से कि मैं अपने नए आवेदन में ऑब्जेक्ट द्वारा ग्रुपिंग नामों पर योजना बना रहा हूं, मैं भी usp को ड्रॉप कर रहा हूं क्योंकि मुझे लगता है कि यह कुछ हद तक बेमानी है, इसके अलावा मुझे इसकी प्रक्रिया बताने के अलावा कुछ ऐसा भी हो सकता है जिसे मैं अपने नाम से काट सकता हूं प्रक्रिया ही।

नया प्रारूप इस प्रकार है

[App]_[Object]_[Action][Process]

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

यह बाद में आसानी से खोजने के लिए चीजों को समूहित करने में मदद करता है, खासकर अगर वहाँ बड़ी मात्रा में स्प्रोक्स होते हैं।

जहाँ एक से अधिक ऑब्जेक्ट का उपयोग किया जाता है, उसके बारे में, मुझे लगता है कि अधिकांश इंस्टेंस में एक प्राथमिक और द्वितीयक ऑब्जेक्ट होता है, इसलिए सामान्य ऑब्जेक्ट में प्राथमिक ऑब्जेक्ट का उपयोग किया जाता है, और द्वितीयक को प्रक्रिया अनुभाग में संदर्भित किया जाता है, उदाहरण के लिए App_Product_AddArtworks।

Comments

यदि एक से अधिक वस्तु शामिल हो तो क्या होगा? उदाहरण के लिए, क्या होगा यदि स्पोक ग्राहक और आदेश तालिका दोनों से जानकारी प्राप्त करता है?

— DOK

धन्यवाद मिच, आइए स्पष्ट करते हैं। यह "ऐप" उपसर्ग वास्तविक ऐप के नाम (या संक्षिप्तिकरण) को इंगित करने वाले एक अन्य संक्षिप्त नाम के लिए एक प्लेसहोल्डर है। एक डेटाबेस को साझा करने वाले 3 ऐप्स के साथ, फिर, ICA_Product_Add, CRM_Product_Add और BPS_Product_Add हो सकते हैं।

— DOK

आप हर प्रक्रिया को 3 ऐप्स के लिए 3 बार क्यों दोहराएंगे? स्टोर प्रोसीजर का पूरा बिंदु एक ही स्थान पर होता है, जहां एक दी गई कार्रवाई होती है। "ICA_Product_Add, CRM_Product_Add और BPS_Product_Add" को नष्ट कर देता है।

— जेसन केस्टर

जेसन, उन स्पोक्स को विभिन्न तालिकाओं में सम्मिलित किया जा सकता है। उनके पास अलग-अलग इनपुट पैरामीटर या रिटर्न मान हो सकते हैं। या उनका अलग व्यवहार हो सकता है। यदि स्प्रोक्स एक ही काम करते हैं, तो मैं सहमत हूं, केवल एक संस्करण होना चाहिए। जैसा कि किसी और ने सुझाव दिया है, साझा स्पार्क्स में कोई उपसर्ग नहीं हो सकता है।

— DOK

यदि आपके पास एक ही प्रक्रिया को कॉल करने वाले कई एप्लिकेशन हैं, तो आपको अतिरिक्त सावधानी बरतने की आवश्यकता है, जो कि खरीद के किसी भी संशोधन से उन कई ऐप को तोड़ सकता है। नामकरण बुद्धिमान है, यह एक ग्रे क्षेत्र है, लेकिन आप इसे सामान्य / वैश्विक या आपके द्वारा देखी गई किसी भी चीज़ का नाम दे सकते हैं। @localghosts: जानकारीपूर्ण होने के लिए धन्यवाद।

— dnolan

Answer 2

यहाँ SQL सर्वर में sp_ उपसर्ग समस्या के बारे में कुछ स्पष्टीकरण दिया गया है।

उपसर्ग sp_ के साथ नामित प्रक्रियाएं मास्टर डेटाबेस में संग्रहीत सिस्टम स्प्रोक्स हैं।

यदि आप अपने उपसर्ग को इस उपसर्ग देते हैं, तो SQL सर्वर पहले मास्टर डेटाबेस में उनके लिए दिखता है, फिर संदर्भ डेटाबेस, इस प्रकार अनावश्यक रूप से संसाधनों को बर्बाद कर रहा है। और, यदि उपयोगकर्ता द्वारा बनाए गए स्पोक का नाम सिस्टम स्प्रो के समान है, तो उपयोगकर्ता द्वारा निर्मित स्प्रो को निष्पादित नहीं किया जाएगा।

Sp_ उपसर्ग इंगित करता है कि स्पार्क सभी डेटाबेस से सुलभ है, लेकिन इसे वर्तमान डेटाबेस के संदर्भ में निष्पादित किया जाना चाहिए।

यहां एक अच्छी व्याख्या है, जिसमें प्रदर्शन हिट का डेमो शामिल है।

यहाँ एक टिप्पणी में चींटी द्वारा प्रदान किया गया एक और सहायक स्रोत है।

Comments

हम्म मैं नहीं समझता। Sp एक प्रदर्शन को हिट क्यों देता है? Usp या gsp ठीक है?

— इरविन रूइजाक्कर्स

@ user2609980 DOK का कहना है कि एसक्यूएल सर्वर sp_पहले मास्टर डीबी में पहले से खरीद के लिए खोज करता है , फिर वर्तमान डीबी में यदि नहीं मिला है

— 21

+1 स्पष्ट रूप से किसी ऐसी चीज़ के बारे में बताने के लिए जिसमें कहीं और अधिक स्पष्ट स्पष्टीकरण हैं। मुझे खबर नहीं है, लेकिन मुझे लगता है कि यह सरल और संक्षिप्त स्पष्टीकरण है जो किसी को शुरू करना है।

— 13

प्रदर्शन हिट के डेमो का लिंक 2001 में लिखे गए एक लेख से है। यह तब से बदल गया है, यहां हारून बर्ट्रेंड द्वारा अधिक गहन लेख (2012 से): sqlperformance.com/2012/10/t-sql-queries/sp_prefix

— माइकल जे

Answer 3

सिस्टम हंगेरियन (उपरोक्त "usp" उपसर्ग की तरह) मुझे थरथराता है।

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

उपसर्ग के बाद का वास्तविक नाम फ़ंक्शन नामकरण से शायद ही अलग है: आमतौर पर एक क्रिया जैसे "जोड़ें", "सेट", "उत्पन्न", "गणना", "हटाएं", आदि, इसके बाद कई और विशिष्ट संज्ञाएं जैसे "उपयोगकर्ता" "," DailyRevenues ", और इसी तरह।

चींटी की टिप्पणी पर प्रतिक्रिया:

1. तालिका और दृश्य के बीच का अंतर उन लोगों के लिए प्रासंगिक है जो डेटाबेस स्कीमा को डिज़ाइन करते हैं, न कि वे जो इसकी सामग्री तक पहुंच या संशोधित करते हैं। स्कीमा विनिर्देश की आवश्यकता के दुर्लभ मामले में, यह खोजने के लिए काफी आसान है। आकस्मिक चयन क्वेरी के लिए, यह अप्रासंगिक है। वास्तव में, मैं एक बड़े लाभ के रूप में तालिकाओं और विचारों का इलाज करने में सक्षम होने का संबंध रखता हूं।
2. कार्यों और संग्रहीत प्रक्रियाओं के विपरीत, एक तालिका या दृश्य का नाम एक क्रिया के साथ शुरू होने की संभावना नहीं है, या कुछ भी हो सकता है लेकिन एक या अधिक संज्ञाएं।
3. एक फ़ंक्शन को स्कीमा उपसर्ग की आवश्यकता होती है जिसे कहा जाता है। वास्तव में, कॉल सिंटैक्स (जो हम उपयोग करते हैं, वैसे भी) एक फ़ंक्शन और संग्रहीत कार्यविधि के बीच बहुत भिन्न होता है। लेकिन यहां तक ​​कि अगर यह नहीं थे, तो 1 के रूप में ही लागू होगा: अगर मैं कार्यों और संग्रहीत प्रक्रियाओं का एक ही इलाज कर सकता हूं, तो मुझे क्यों नहीं करना चाहिए?

Comments

Sooo, आप कैसे जानते हैं कि क्या आप एक प्रक्रिया, एक कार्य, एक दृश्य, एक तालिका, या कुछ और के साथ बातचीत कर रहे हैं?

— एंट

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

— मार्क स्टॉक

लेकिन यह हंगेरियन नहीं है। "Usp" एक हंगेरियन चर घोषणा नहीं है। "यू" "अपडेट" के लिए खड़ा नहीं होता है, यह "उपयोगकर्ता" के लिए खड़ा है, जैसा कि "उपयोगकर्ता परिभाषित संग्रहीत कार्यविधि" में है, और यह केवल एसक्यूएल सर्वर से मास्टर डीबी में देख रहे हर बार आपकी संग्रहीत प्रक्रिया की खोज कर रहा है। स्वाभाविक रूप से, अन्य तरीके हैं, लेकिन "usp" को आमतौर पर व्यापक रूप से कई कोर में एक मानक माना जाता है, और जो मैंने देखा है वह अच्छी तरह से काम करता है। यह Microsoft द्वारा भी पढ़ाया जाता है, और एक Microsoft ने नामकरण सम्मेलन की सिफारिश की है: msdn.microsoft.com/en-us/library/ms124456(v=SQL.100).aspx

— asus3000

Answer 4

मैंने वर्षों में सभी विभिन्न प्रणालियों का बहुत अधिक उपयोग किया है। मैंने आखिरकार इसे विकसित किया, जिसका मैं आज भी उपयोग कर रहा हूं:

उपसर्ग:

• जीन - जनरल: CRUD, ज्यादातर
• rpt - रिपोर्ट: स्व-व्याख्यात्मक
• tsk - कार्य: आमतौर पर प्रक्रियात्मक तर्क के साथ कुछ, अनुसूचित नौकरियों के माध्यम से चलाते हैं

कार्रवाई विनिर्देशक:

Ins - INSERT
Sel - SELECT
Upd - UPDATE
Del - DELETE

(ऐसे मामलों में जहां प्रक्रिया कई काम करती है, समग्र लक्ष्य का उपयोग एक्शन स्पेसियर को चुनने के लिए किया जाता है। उदाहरण के लिए, ग्राहक INSERT को प्रीप वर्क के अच्छे सौदे की आवश्यकता हो सकती है, लेकिन समग्र लक्ष्य INSERT है, इसलिए "Ins" चुना जाता है।

वस्तु:

जीन (CRUD) के लिए, यह तालिका या दृश्य नाम प्रभावित हो रहा है। आरटीपी (रिपोर्ट) के लिए, यह रिपोर्ट का संक्षिप्त विवरण है। Tsk (टास्क) के लिए यह कार्य का संक्षिप्त विवरण है।

वैकल्पिक क्लेरिफायर्स:

ये प्रक्रिया की समझ बढ़ाने के लिए उपयोग की जाने वाली जानकारी के वैकल्पिक बिट्स हैं। उदाहरणों में "बाय", "फॉर", आदि शामिल हैं।

प्रारूप:

[उपसर्ग] [क्रिया विनिर्देशक] [इकाई] [वैकल्पिक क्लेरिफ़ायर]

प्रक्रिया के नाम के उदाहरण:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

Comments

अब, उपसर्ग पर एक दिलचस्प कदम है। कि उनके उपयोग से sprocs अलग करने के लिए एक अच्छा तरीका की तरह लग रहा है।

— डीओके

Answer 5

TableName_WhatItDoes

• Comment_GetByID

• ग्राहकों का विवरण

• UserPreference_DeleteByUserID

कोई उपसर्ग या मूर्खतापूर्ण बाल बकवास। बस तालिका का नाम यह सबसे निकटता से जुड़ा हुआ है, और यह क्या करता है का एक त्वरित विवरण।

ऊपर एक चेतावनी: मैं व्यक्तिगत रूप से हमेशा अपने सभी ऑटोग्रोजेनेटेड CRUD को zCRUD_ के साथ उपसर्ग करता हूं ताकि यह उस सूची के अंत में हो जाए जहां मुझे इसे देखने की जरूरत नहीं है।

Comments

बाकी हिस्सों से "z" वस्तुओं को अलग करना एक महान विचार की तरह लगता है।

— DOK

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

— astrosteve

और क्या होगा यदि आपके पास कई तालिकाओं में शामिल होने वाली क्वेरी है?

— leandronn

Answer 6

sp_SQL सर्वर में संग्रहीत कार्यविधि नाम को प्रारंभ करना खराब है क्योंकि सिस्टम sprocs सभी sp_ से शुरू होता है। सुसंगत नामकरण (हॉबोब्लिन-डोम की सीमा तक) उपयोगी है क्योंकि यह डेटा शब्दकोश के आधार पर स्वचालित कार्यों को सुविधाजनक बनाता है। SQL Server 2005 में उपसर्ग थोड़े कम उपयोगी होते हैं क्योंकि यह स्कीमा का समर्थन करता है, जिसका उपयोग विभिन्न प्रकार के नामस्थानों के लिए किया जा सकता है जिस तरह से उपयोग किए गए नामों पर उपसर्ग करते हैं। उदाहरण के लिए, एक स्टार स्कीमा पर, एक मंद और तथ्य स्कीमा हो सकता है और इस सम्मेलन द्वारा तालिकाओं को संदर्भित कर सकता है ।

संग्रहीत प्रक्रियाओं के लिए, प्रीफ़िक्सिंग सिस्टम स्प्रोक्स से एप्लिकेशन स्पेंट को इंडेंट करने के उद्देश्य से उपयोगी है। up_बनाम sp_डेटा शब्दकोश से गैर-सिस्टम संग्रहीत प्रक्रियाओं की पहचान करना अपेक्षाकृत आसान बनाता है।

Comments

नामकरण स्प्रोक्स "स्प_" गति के लिए एक बहुत बुरा विचार है, क्योंकि एसक्यूएल सर्वर इस धारणा के आधार पर अपने लुकअप को अनुकूलित करने की कोशिश करता है कि वे सिस्टम प्रक्रियाएं हैं। यहाँ एक नज़र है, नीचे 5 वें बिंदु: rakph.wordpress.com/2008/04/19/tips-store-procedure

— Ant

Answer 7

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

नामकरण सम्मेलन स्वाद का विषय है और कुछ ऐसा होना चाहिए जो आपको प्रोजेक्ट शुरू होने पर अन्य सभी डेवलपर्स से सहमत होना चाहिए।

Comments

पैकेज अच्छे हैं। SQL सर्वर 2005 के साथ शुरू, प्रबंधन स्टूडियो संबंधित sprocs और अन्य SQL बयानों को संग्रहीत करने के लिए "समाधान" बनाने में सक्षम बनाता है।

— डीओके

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

— कंसर्नडऑफटुनब्रिजवेल्स

Answer 8

छोटे डेटाबेस के लिए, मैं uspTableNameOperationName, जैसे uspCustomerCreate, uspCustomerDelete, आदि का उपयोग करता हूं। यह 'मुख्य' इकाई द्वारा समूह बनाने की सुविधा देता है।

बड़े डेटाबेस के लिए, उन्हें एक साथ रखने के लिए एक स्कीमा या सबसिस्टम नाम, जैसे प्राप्त करना, खरीदना, आदि जोड़ें (क्योंकि sql सर्वर उन्हें वर्णानुक्रम में प्रदर्शित करना पसंद करता है)

मैं नामों में संक्षिप्तता से बचने की कोशिश करता हूं, स्पष्टता के लिए (और परियोजना पर नए लोगों को आश्चर्य नहीं है कि 'UNAICFE' का क्या मतलब है क्योंकि स्पॉर्ट का नाम uspUsingNoAblookationsIncreasesClarityFireEveryone है)

Comments

हाँ, विशेष रूप से संक्षिप्तीकरण के लिए धन्यवाद।

— DOK

@ [DOK]: आपका स्वागत है - क्या, कोई अपवोट नहीं? ;-)

— स्टीवन ए। लोव

स्टीव, आपको एक उत्थान मिला। मैं जवाबों और टिप्पणियों की हड़बड़ाहट को पढ़ने में बहुत व्यस्त था, और इस बात के बारे में उत्तेजित करना कि कौन सा उत्तर "सर्वश्रेष्ठ" है।

— DOK

@ [डीओके]: धन्यवाद; 'सर्वोत्तम' उत्तर संभवतः वह संयोजन है जो आपकी स्थिति के लिए समझ में आता है।

— स्टीवन ए। लोवे

Answer 9

मैं वर्तमान में एक प्रारूप का उपयोग करता हूं जो निम्नलिखित की तरह है

संकेतन:

[पूर्व] [आवेदन] [मॉड्यूल] _ [नाम]

उदाहरण:

P_CMS_USER_UserInfoGet

मैं कुछ कारणों से इस संकेतन को पसंद करता हूं:

• बहुत ही सरल उपसर्ग के साथ शुरू करके कोड को केवल उपसर्ग के साथ भीख देने वाली वस्तुओं को निष्पादित करने के लिए लिखा जा सकता है (उदाहरण के लिए, SQL इंजेक्शन को कम करने के लिए)
• हमारे बड़े परिवेश में, कई टीमें अलग-अलग ऐप पर काम कर रही हैं, जो एक ही डेटाबेस आर्किटेक्चर के चलते हैं। अनुप्रयोग संकेतन नामित करता है कि कौन सा समूह सपा का मालिक है।
• मॉड्यूल और नाम अनुभाग केवल उत्तराधिकार को पूरा करते हैं। सभी नामों को समूह / ऐप, मॉड्यूल, फ़ंक्शन से उत्तराधिकार में मिलान करने में सक्षम होना चाहिए।

Answer 10

मैं हमेशा उपयोग करता हूं:

usp [टेबल का नाम] [क्रिया] [अतिरिक्त विस्तार]

"TblUser" नामक एक तालिका को देखते हुए, जो मुझे देता है:

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

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

जब तक SQL सर्वर IDE में संपादक विजुअल स्टूडियो के रूप में अच्छा है मैं उपसर्गों को रख रहा हूं।

Answer 11

अनुप्रयोग प्रीफ़िक्स_ ऑपरेशन प्रीफ़िक्स_ में शामिल डेटाबेस ऑब्जेक्ट्स का विवरण (अंडरस्कोर के बीच रिक्त स्थान - उन्हें दिखाई देने के लिए रिक्त स्थान डालना था) ।

ऑपरेशन उपसर्ग हम उपयोग करते हैं -

• " मिलता है " - एक recordet देता है
• " इन्स " - डेटा सम्मिलित करता है
• " Upd " - अपडेट डेटा
• " डेल " - डेटा को हटाता है

जैसे

wmt_ ins _ ग्राहक _details

"कार्यबल प्रबंधन उपकरण, ग्राहक तालिका में विवरण डालें"

फायदे

समान एप्लिकेशन से संबंधित सभी संग्रहीत कार्यविधियाँ नाम से एक साथ समूहीकृत की जाती हैं। समूह के भीतर, एक ही तरह के ऑपरेशन (जैसे आवेषण, अद्यतन आदि) को अंजाम देने वाली संग्रहीत प्रक्रियाएँ एक साथ समूहीकृत होती हैं।

यह प्रणाली हमारे लिए अच्छी तरह से काम करती है, लगभग अनुमानित है। मेरे सिर के ऊपर से एक डेटाबेस में 1000 संग्रहीत कार्यविधियाँ।

अब तक इस दृष्टिकोण के किसी भी नुकसान में नहीं आए हैं।

Comments

मैं आम तौर पर अंडरस्कोर के उपयोग को घृणा करता हूं, लेकिन जिस तरह से आप इसका उपयोग करते हैं - न केवल उपसर्ग को अलग करने के लिए, बल्कि ऑपरेशन को अलग करने के लिए भी - सैकड़ों स्प्रोक्स की सूची को स्कैन करते समय इसे खोजना आसान होगा। Pretty_neat_idea।

— DOK

Answer 12

GetXXX - @ID पर आधारित XXX हो जाता है

GetAllXXX - सभी XXX हो जाता है

PutXXX - @ @ पारित होने पर XXX सम्मिलित करता है -1; और अपडेट

DelXXX - @ID पर आधारित XXX को हटाता है

Answer 13

मुझे लगता है कि usp_ नामकरण सम्मेलन से किसी का भला नहीं होता।

अतीत में, मैंने CRUD ऑपरेशन के लिए Get / Update / Insert / Delete उपसर्गों का उपयोग किया है, लेकिन अब चूंकि मैं अपने ज्यादातर CRUD काम करने के लिए Linq से SQL या EF का उपयोग करता हूं, ये पूरी तरह से चले गए हैं। चूँकि मेरे नए अनुप्रयोगों में मेरे पास बहुत कम संग्रहित procs हैं, इसलिए नामकरण सम्मेलनों में कोई फर्क नहीं पड़ता है जैसे वे ;-);

Comments

हर स्पूस को _usp के साथ प्रीफ़िक्स करने से उनके बीच अंतर करने में मदद नहीं मिलती है। मुझे लगता है कि कुछ डीबीए उस उपसर्ग की तरह है क्योंकि यह डेटाबेस ऑब्जेक्ट प्रकार को इंगित करता है। शायद हम उनमें से एक से सुनेंगे जो इसे पसंद करता है।

— DOK

Answer 14

वर्तमान, जिस एप्लिकेशन पर मैं काम कर रहा हूं, उसके लिए हमारे पास एक उपसर्ग है जो एप्लिकेशन नाम (चार लोअरकेस अक्षर) की पहचान करता है। इसका कारण यह है कि हमारा आवेदन एक ही डेटाबेस में एक विरासत अनुप्रयोग के साथ सह-मौजूद होना चाहिए, इसलिए उपसर्ग एक होना चाहिए।

यदि हमारे पास विरासत की बाधा नहीं थी, तो मुझे पूरा यकीन है कि हम एक उपसर्ग का उपयोग नहीं करेंगे।

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

हमारी टीम पर विशिष्ट संग्रहित प्रक्रिया के नाम होंगे:

shopGetCategories
shopUpdateItem

Comments

ठीक है, आप कभी नहीं जानते हैं, जब आप एक डेटाबेस पर काम कर रहे होते हैं, जो एक ऐप के लिए समर्पित होता है, चाहे बाद में उसी डेटाबेस का उपयोग करके एक और ऐप होगा। आपकी स्थिति में, यह सुनिश्चित करता है कि स्पर्स को अलग करने में मदद करें।

— DOK

Answer 15

मुझे नहीं लगता कि यह वास्तव में ठीक मायने रखता है कि आपका उपसर्ग इतना लंबा है कि आप तार्किक और सुसंगत हैं। व्यक्तिगत रूप से मैं उपयोग करता हूं

स्पू_ [क्रिया विवरण] [प्रक्रिया विवरण]

जहाँ एक्शन विवरण विशिष्ट क्रियाओं की एक छोटी श्रृंखला है जैसे कि प्राप्त करें, सेट करें, संग्रह करें, सम्मिलित करें, हटाएं आदि। प्रक्रिया विवरण कुछ छोटा है लेकिन विवरणात्मक है, उदाहरण के लिए

spu_archiveCollectionData 

या

spu_setAwardStatus

मैं अपने कार्यों को इसी तरह नाम देता हूं, लेकिन udf_ के साथ उपसर्ग

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

Comments

spu_, दिलचस्प है। SQL सर्वर sp_ समस्या को dodges।

— DOK

Answer 16

SQl सर्वर coz में sp_ * से बचें सभी सिस्टम संग्रहीत कार्यविधियाँ sp_ से शुरू होती हैं और इसलिए सिस्टम के लिए नाम के अनुरूप वस्तु को खोजना अधिक कठिन हो जाता है।

तो अगर आप sp_ चीजों के अलावा किसी और चीज से शुरुआत करते हैं तो चीजें आसान हो जाती हैं।

तो हम शुरू करने के लिए Proc_ के एक सामान्य नामकरण का उपयोग करते हैं। यदि एक बड़ी स्कीमा फ़ाइल के साथ प्रस्तुत की गई प्रक्रियाओं को पहचानना आसान हो जाता है।

इसके अलावा हम एक उपसर्ग असाइन करते हैं जो फ़ंक्शन की पहचान करते हैं। पसंद

Proc_Poll_Interface, Proc_Inv_Interface आदि।

यह हमें उन सभी संग्रहित प्रोक को खोजने की अनुमति देता है जो पोलल बनाम बनाम इन्वेंटरी आदि का काम करता है।

किसी भी तरह उपसर्ग प्रणाली आपकी समस्या डोमेन पर निर्भर करती है। लेकिन अल ने कहा और ऐसा ही कुछ किया जाना चाहिए भले ही लोगों को संपादन के लिए खोज ड्रॉप डाउन में संग्रहीत प्रक्रिया का पता लगाने की अनुमति देना हो।

अन्य उदाहरण के कार्य।

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

हमने फ़ंक्शन का नामकरण किया है नामकरण कोज़ प्रोक्स तालिकाओं जैसी स्थिर वस्तुओं के बजाय कोड / फ़ंक्शन के समान हैं। यह मदद नहीं करता है कि Procs एक से अधिक टेबल के साथ काम कर सकता है।

यदि खरीद को किसी एक नाम से नियंत्रित किया जा सकता है, तो इसका मतलब है कि आपकी खरीदारी जरूरत से ज्यादा हो रही है और इसका समय उन्हें फिर से विभाजित करने का है।

उम्मीद है की वो मदद करदे।

Answer 17

मैं थ्रेड में देर से शामिल हुआ, लेकिन मैं यहां अपना उत्तर दर्ज करना चाहता हूं:

मेरी पिछली दो परियोजनाओं में अलग-अलग रुझान हैं, जैसे कि एक में हमने प्रयोग किया है:

डेटा प्राप्त करने के लिए: s <tablename> _G
डाटा डिलीट करने के लिए: s <tablename> _D
डेटा डालने के लिए: s <tablename> _I
डेटा अपडेट करने के लिए: s <tablename> _U

इस नामकरण सम्मेलनों का भी आगे-पीछे dt शब्द उपसर्ग करके किया जाता है ।

उदाहरण:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

हमारे आवेदन में उपरोक्त नामकरण सम्मेलनों की सहायता से हमारे पास नामों को याद रखने के लिए एक अच्छा और आसान तरीका है।

दूसरी परियोजना में हमने लिल अंतर के साथ समान नामकरण परंपराओं का उपयोग किया:

डेटा प्राप्त करने के लिए: sp_ <tablename> G
डेटा हटाने के लिए: sp_ <tablename> D
डेटा सम्मिलित करने के लिए: sp_ <tablename> I
डेटा अपडेट करने के लिए: sp_ <tablename> U

उदाहरण:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU

Comments

दिलचस्प। मैंने इसे कभी भी इस तरह से नहीं देखा है, लेकिन सही नामों को याद रखना या अनुमान लगाना आसान है।

— DOK

धन्यवाद DOK, हाँ, यह याद रखना आसान है और हम डेवलपर को किसी भी जटिलता से मुक्त महसूस करते हैं

— गौरव अरोरा

क्यों नहीं _C _R _U _D?

— onedaywhen

@onedaywhen - इसका एक अच्छा विचार है, मैं हमारे DBA को सुझाव दूंगा, इसलिए हम अपने अनुसार नामकरण रूपांतरण बनाए रख सकते हैं। लेकिन, इस नामकरण सम्मेलन का मुख्य उद्देश्य सभी वस्तु को सही ढंग से प्रस्तुत करना है, जब तक कि मुझे कुछ भी याद न हो ...

— गौरव अरोरा

"sp_" उपसर्ग अनुशंसित नहीं है।

— पीयू जूल