उपसर्ग एसक्यूएल फ़ंक्शन नाम क्यों?

Question

एक परिदृश्य क्या है जो SQL सर्वर में फ़ंक्शन नामों पर ff_GetName जैसे उपसर्गों का उपयोग करने का एक अच्छा कारण है? ऐसा लगता है कि यह अनावश्यक होगा क्योंकि आमतौर पर इसके उपयोग के संदर्भ से यह स्पष्ट हो जाएगा कि यह एक कार्य है। मैंने किसी अन्य भाषा का उपयोग नहीं किया है जिसकी कभी भी फ़ंक्शंस पर उपसर्ग की आवश्यकता है, और मैं एक अच्छा परिदृश्य नहीं सोच सकता जो दिखाएगा कि SQL क्यों अलग है।

मेरी एकमात्र सोच यह है कि शायद पुराने आईडीई में यह एक साथ समूहबद्ध करने के लिए उपयोगी था जब डेटाबेस ऑब्जेक्ट्स सभी एक साथ सूचीबद्ध थे, लेकिन आधुनिक आईडीई पहले से ही यह स्पष्ट कर देता है कि कोई फ़ंक्शन क्या है।

Answer 1

आप पुराने IDEs

एक डीबीए के रूप में के बारे में सही हैं, एसक्यूएल सर्वर एंटरप्राइज़ प्रबंधक (SQL सर्वर 2000 और 7.0) का उपयोग कर अनुमतियाँ ठीक करने की कोशिश है, यह पूरा मैथुन अनुमतियाँ देखने की कोशिश कर रहा था। यदि आपके पास यूएफएन या यूएसपी या वीडब्ल्यू था तो जीयूआई ने डेटा प्रस्तुत करने के कारण चीजों को समूहबद्ध करना आसान हो गया।

यह कहकर कि, यदि आपके पास SELECT * FROM Thing है, तो चीज क्या है? एक दृश्य या एक टेबल? यह आपके लिए डेवलपर के रूप में काम कर सकता है लेकिन तैनात होने पर यह क्रैश हो जाएगा क्योंकि आप तालिका पर अनुमति नहीं देते हैं: केवल विचार या procs। निश्चित रूप से vwThing आपके रक्तचाप को नीचे रखेगा ...?

यदि आप स्कीमा का उपयोग करते हैं, तो यह अप्रासंगिक हो जाता है। आप अपनी वस्तुओं को "नामस्थान" कर सकते हैं।उदाहरण के लिए, अन्य स्कीमा में "डेटा" में तालिकाओं और अन्य वस्तुओं के ग्राहक प्रति जैसे WebGUI

संपादित करें:

समारोह। आपके पास टेबल मूल्यवान और स्केलर फ़ंक्शन हैं। यदि आप कोड "VerbNoun" अवधारणा के साथ चिपके रहते हैं, तो आप कैसे जानते हैं कि बिना किसी अन्य सुराग के कौन सा है। (बेशक, यह भी हो सकता है नहीं क्योंकि वस्तु नाम अद्वितीय हैं)

SELECT dbo.GetName() FROM MyTable 
SELECT * FROM dbo.GetName() 

आप एक तालिका मूल्यवान समारोह सूचित करने के लिए एक बहुवचन का उपयोग करते हैं, यह यकीनन बदतर

SELECT dbo.GetName() FROM MyTable 
SELECT * FROM dbo.GetNames() 

है जबकि यह कम अस्पष्ट है , हालांकि कुछ लोगों के लिए आक्रामक ;-)

SELECT dbo.sfnGetName() FROM MyTable 
SELECT * FROM dbo.tfnGetName() 

स्कीमा के साथ। और कोई नाम अस्पष्टता नहीं है।

SELECT ScalarFN.GetName() FROM MyTable 
SELECT * FROM TableFN.GetName() 

आपकी "कोई अन्य भाषा" टिप्पणी लागू नहीं होती है। एसक्यूएल सी #, जावा, एफ #, एडीए (ओके, पीएल/एसक्यूएल हो सकता है) की तरह संरचित नहीं है, वीबीए, जो भी हो: कोई ऑब्जेक्ट या नेमस्पेस पदानुक्रम नहीं है। नहीं Object.DoStuff विधि सामान।

एक उपसर्ग केवल आपके समझदार रखने के लिए ...

Answer 2

fn_ के साथ फ़ंक्शन नामों को उपसर्ग करने की आवश्यकता नहीं है t_ (एक सम्मेलन मैंने देखा है) के साथ तालिका नामों को उपसर्ग करने की आवश्यकता से कहीं अधिक है। इस प्रकार का व्यवस्थित उपसर्ग उन लोगों द्वारा उपयोग किया जाता है जो अभी तक भाषा के साथ सहज नहीं हैं और जिन्हें कोड को समझने के लिए अतिरिक्त सहायता के रूप में सम्मेलन की आवश्यकता है।

Answer 3

मैं उपसर्गों का प्रशंसक नहीं हूं, लेकिन शायद एक फायदा यह हो सकता है कि ये fn_ उपसर्ग यह पहचानने में आसान हो सकता है कि एक विशेष कार्य उपयोगकर्ता के परिभाषित है, बजाय अंतर्निहित।

Answer 4

क्या एक परिदृश्य है कि एक अच्छा कारण एक मिसाल है उपसर्गों

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

Answer 5

हमारे बारे में हमारी कंपनी में हमारे पास कई दर्दनाक बैठकें थीं। आईएमओ, हमें किसी भी ऑब्जेक्ट नाम पर उपसर्ग की आवश्यकता नहीं है। हालांकि, यदि आप दृश्य का नाम अंतर्निहित तालिका नाम से संघर्ष कर सकते हैं, तो आप उन्हें विचारों पर रखने के लिए तर्क दे सकते हैं।

किसी भी मामले में, कोई भी SQL आवश्यकता नहीं है जो उपसर्ग का उपयोग किया जाए, और स्पष्ट रूप से, आईएमओ, उनके पास कोई वास्तविक मूल्य नहीं है।

Answer 6

एक (और एकमात्र) लाभ मैं सोच सकता हूं कि यह एक परिणामस्वरूप लागू उपसर्ग योजना इंटेलिजेंस/स्वत: पूर्णता का उपयोग कर सकती है क्योंकि संबंधित कार्यक्षमता स्वचालित रूप से एक साथ समूहीकृत होती है।

Answer 7

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

Answer 8

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

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

बेशक, अधिकतर नामकरण सम्मेलन न केवल बुरा है, इसका भी पालन नहीं किया जाता है और नाम असंगत हैं। उस स्थिति में, आप बनने के लिए बेकार है ...

Answer 9

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