क्या SQL कीवर्ड के लिए ऊपरी मामले का उपयोग करने का एक अच्छा कारण है? [बन्द है]

128

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

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

sql  coding-style  capitalization 
— हर्टेंटो लेट
स्रोत
9
कैप्स लॉक कुंजी को आज़माएं। :)
— मुशीनेसिस
7
मुझे अभी भी CAPS LOCK चालू करना है जब मैं कीवर्ड लिखना चाहता हूं और तब बंद कर देता हूं जब मैं कीवर्ड नहीं लिख रहा हूं और CAPS LOCK को फिर से और इसी तरह चालू करता हूं। यह सिर्फ एक परेशानी है।
— हर्टेंटो लेट
17
CAPS wha ... ओह, आपका मतलब मेरी तीसरी Ctrl कुंजी है?
— डेव शेरोहमान
2
IIRC, मज़ेदार बात यह है कि यदि आप MSSQL में sp_ प्रक्रियाओं की जाँच करते हैं, तो वे सभी कम स्थिति में हैं।
— बेंजोल
1
@ बैंजोल, उन सभी को नहीं, लेकिन निश्चित रूप से उनमें से बहुत कुछ sp_who की तरह। यह कम से कम उसी स्पोक में सुसंगत होने की कोशिश करने के लिए अच्छा विचार है , जो Microsoft बहुत सारे "मामलों" में नहीं है। जानबूझ का मजाक। LOL
— गॉर्डन बेल

जवाबों:

107

यह सिर्फ स्टाइल की बात है, शायद उन दिनों में हुई थी जब संपादकों ने कोड कलरिंग नहीं की थी।

मैं सभी ऊपरी मामलों को पसंद करता था, लेकिन मैं अब सभी निचले हिस्से की ओर झुक रहा हूं।

— मिच गेहूं
स्रोत
6
+1 मुझे लगता है कि मैं केवल कीवर्ड के लिए सभी निम्नतर का उपयोग करने वाला नहीं था।
— नृत्य
2
मैं इस धारणा के साथ जाऊंगा कि यह उन दिनों में वापस आ जाता है जब संपादक कोड कलरिंग नहीं करते थे।
— बेंजोल
10
मुझे पूरा यकीन है कि यह उन दिनों में वापस चला जाता है जब कई मशीनें लोअरकेस वर्णों का समर्थन नहीं करती थीं।
— नैट सीके
1
मुझे लगता है कि यह रंग पर नज़र रखने से पहले के दिनों में वापस चला जाता है;)
— 2
150

व्यक्तिगत रूप से, मैं मेरे बारे में मेरी SQL YELLING पसंद नहीं है। बेसिक या कॉबोल का मुझे रिमाइंड करें।

इसलिए मैं डेटाबेस ऑब्जेक्ट नाम मिक्स्डकेस के साथ अपनी टी-एसक्यूएल लोअरकेस पसंद करता हूं।

यह पढ़ना बहुत आसान है, और शाब्दिक और टिप्पणियाँ बाहर खड़े हैं।

— गॉर्डन बेल
स्रोत
8
यह स्वाद का मामला है। मेरे अनुभव में, चिल्लाना की मात्रा बहुत अधिक नहीं है - मैं ऊपरी मामले के कीवर्ड पसंद करता हूं क्योंकि इसे पढ़ना बहुत आसान है और शाब्दिक और टिप्पणियां बाहर खड़ी हैं।
— जोनाथन लेफ्लर
93
+1 के लिए "मैं मेरे ऊपर मेरी एसक्यूएल
— सेलिंग
8
मुझे कोई भी भाषा मुझे पसंद नहीं है, लेकिन यह सवाल नहीं उठता कि क्या ऊपरी मामला SQL में एक अच्छा विचार है।
— bignose
85

SQL IS OLD है। UPPER CASE IS SHOUTING आईटी लूज स्ट्रेंथ एंड पर्फ्सस ऑली।

यकीनन सच है, उन लोगों में से कोई भी SQL भाषा के लिए विशेष कारणों को संबोधित नहीं करता है कि ऊपरी मामले के कीवर्ड एक अच्छा सम्मेलन क्यों हैं।

कई नई भाषाओं के विपरीत, SQL में बड़ी संख्या में कीवर्ड हैं और सिंटैक्स को मानसिक रूप से पार्स करने के लिए कीवर्ड बनाम पहचानकर्ताओं को अलग करने की पाठक की क्षमता पर निर्भर करता है ।

आपके प्रश्न का सीधा उत्तर, तब, " SQL कोड के पाठक को अपरकेस कीवर्ड से इतना लाभ क्यों होता है, इसका उत्तर अधिक है , जब यह अधिकांश आधुनिक भाषाओं के लिए सही नहीं है?"

  • किसी के सिर में कीवर्ड रखने पर भरोसा करने के लिए कई आधुनिक भाषाओं के लिए उचित है, लेकिन SQL के लिए अनुचित ; इसके बहुत सारे कीवर्ड हैं, और बहुत सारे वेरिएंट हैं।

  • विराम चिह्न पर भरोसा करना अधिकांश आधुनिक भाषाओं के लिए उचित है, लेकिन SQL के लिए अनुचित है ; सिंटैक्स को इंगित करने के लिए कीवर्ड के सटीक क्रम के आधार पर इसके पास बहुत कम है।

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

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

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

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

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

— बड़ी नाक
स्रोत
मुझे लगता है कि इस सवाल का करीबी कारण काफी अच्छा है। आपका उत्तर अच्छी तरह से समझाया गया है, लेकिन अभी भी एक सा राय आधारित है। मुझे एसक्यूएल नहीं लगता है कि इतने सारे कीवर्ड हैं। वैसे भी, 50 से अधिक लगातार खोजशब्दों के बाद, आप कितनी बार दूसरों को देखते हैं? क्या यह अभी भी उन्हें अपरकेस दिखाने के लिए मायने रखता है? चूँकि वे निराले हैं, वे वैसे भी ध्यान आकर्षित करते हैं, क्या वे नहीं हैं? बेशक, उन लानतनामे 'गैर-आरक्षित कीवर्ड' को sql-server के रूप में throwकुछ विशेष उपचार के लायक है, लेकिन अपरकेस कई के बीच एक विकल्प है।
— Frédéric
1
@ Frédéric, आप यह तर्क देते हैं कि पाठक को कीवर्ड के रूप में चिह्नित किए जाने वाले कम-ज्ञात कीवर्ड की आवश्यकता नहीं है। नहीं, ऐसे शब्द ठीक से ध्यान आकर्षित नहीं करते हैं क्योंकि पाठक से यह जानने की उम्मीद नहीं की जा सकती कि वे कीवर्ड हैं; इसलिए उन्हें किसी अन्य की तरह कीवर्ड के रूप में प्रतिष्ठित होने की आवश्यकता है।
— bignose
हो सकता है कि मैं एसक्यूएल के बारे में बहुत अधिक अनभिज्ञ हूं, हालांकि मेरी एसक्यूएल के साथ प्रोग्रामिंग के कई वर्षों, लेकिन अब तक मेरा मानना ​​है कि हमेशा लगभग तुरंत कीवर्ड देखा जाता है जो मैं नहीं जानता था, क्योंकि वे एक असामान्य एसक्यूएल निर्माण में परिणाम थे, कम से कम किसी ऐसे व्यक्ति के लिए जो नहीं करता है उनको जानो।
— Frédéric
33

गॉर्डन बेल के उदाहरण बिल्कुल सही नहीं हैं; आम तौर पर, केवल कीवर्ड हाइलाइट किए जाते हैं, संपूर्ण क्वेरी नहीं। उनका दूसरा उदाहरण इस प्रकार होगा:

SELECT name, id, xtype, uid, info, status, 
base_schema_ver, replinfo, parent_obj, crdate, 
ftcatid, schema_ver, stats_schema_ver, type, 
userstat, sysstat, indexdel, refdate, version, 
deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
WHERE category = 0
AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1

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

मेरी कंपनी में, हम अपने एसक्यूएल फॉर्मेटिंग के साथ थोड़ा आगे जाते हैं।

SELECT      name, id, xtype, uid, info, status, 
            base_schema_ver, replinfo, parent_obj, crdate, 
            ftcatid, schema_ver, stats_schema_ver, type, 
            userstat, sysstat, indexdel, refdate, version, 
            deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
LEFT JOIN systhingies ON
    sysobjects.col1=systhingies.col2
WHERE category = 0
    AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1
— davidtbernal
स्रोत
1
हाँ, मुझे यह पसंद है।
— डेविड द मैन
6
समस्या यह है ... यदि आप प्रॉम्प्ट पर एड-हॉक कमांड चलाते समय कैपिटल करते हैं, तो आप हमेशा १/२ उतने ही तेज़ होंगे जितने कि उन लोगों को कैपिटलाइज़ नहीं किया जाता है, जब आपको कभी भी प्रोडक्शन में एड-हॉक कमांड चलाने होते हैं मायने रखती है। इसलिए मैं इसे सभी लोअर-केस लिखता हूं और फिर चेक-इन से पहले "इसे सुशोभित करता हूं" जब कोई शिकायत करता है कि वे इसे नहीं पढ़ सकते क्योंकि उन्हें पता नहीं है कि सिंटैक्स हाइलाइटर कैसे चलाना है। और मुझे आपके बारे में पता नहीं है, लेकिन साल में 3 बार मुझे उत्पादन की गति में तदर्थ कमांड चलाना पड़ता है, इसलिए वास्तव में 50% कार्यदिवस हैं जो मैंने सभी निचले मामलों में परीक्षण-प्रश्न लिखने का अभ्यास किया है जो वास्तव में भुगतान करता है।
7
और मेरी कंपनी के डेटाबेस में (90 के दशक में कहीं भी बनाया गया) सभी टैबलेनम्स, कॉलम, इंडेक्स, स्टोर की गई प्रक्रिया आदि सभी बड़े किए गए हैं, इसलिए हम SQL कीवर्ड को कम करने के लिए जाते हैं। ;)
— एंड्रियास
1
वाह १/२ तेज। मुझे ऐसा नहीं लगता!
— इरहब अल असिमी
33

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

ध्यान दें कि कुछ लोग इस बात को दोहराते हैं कि हम एक दिन का हिस्सा बनेंगे और अपनी क्वेरी को तेजी से बढ़ाएँगे।

— लुकास ईडर
स्रोत
तो, आज एक अच्छा कारण नहीं है।
— bignose
1
@ हस्ताक्षर: नहीं, पूरी तरह से नहीं!
— लुकास एडर
1
मुझे लगता है कि यह सबसे अच्छा जवाब है। अफसोस की बात है, मुझे एसक्यूएल कीवर्ड में लोअरकेस से नफरत है और मुझे लोअरकेस पसंद नहीं है, क्या मैं पागल हूं?
— इरहब अल असिमी
@IharobAlAsimi हाँ आप CRAZY हैं। आप कमज़ोर मामले में क्यों उलझते हैं, लेकिन चुटकी बजाते हैं?
— लुकास ईडर
24

हमारे द्वारा पढ़े गए पाठ में 10% से कम अक्षर ऊपरी स्थिति हैं। इसलिए हमारे दिमाग ऊपरी मामलों की तुलना में कम केस अक्षरों को पहचानने में अधिक उत्सुक हैं। अध्ययनों से पता चला है कि ऊपरी मामले के पाठ को पढ़ने में अधिक समय लगता है। यहाँ सिर्फ एक उदाहरण है:

http://www.guardian.co.uk/media/mind-your-language/2010/oct/04/new-york-street-signs-capitals

उपरोक्त उदाहरण मैं समझता हूं कि जब आप सिर्फ एक या दो शब्दों के बारे में बात कर रहे होते हैं तो भी इससे फर्क पड़ता है।

— AaronLS
स्रोत
5
हम ऑल-कैप्स में एक उपन्यास पढ़ने के बारे में बात नहीं कर रहे हैं; हम उन मुट्ठी भर खोजशब्दों के बारे में बात कर रहे हैं जो केवल पाठ का एक हिस्सा हैं।
— केसी
6
आप बात याद कर रहे हैं। यह इस बारे में नहीं है कि हम कितने शब्दों को पढ़ रहे हैं, यह इस बारे में है कि हमारे मस्तिष्क को जल्दी से क्या करने के लिए प्रशिक्षित किया गया है। उदाहरण के लिए एक सड़क का संकेत निश्चित रूप से एक उपन्यास नहीं है, लेकिन वे एक ही निष्कर्ष पर आए हैं। जब हम पढ़ना सीखते हैं, तो हम प्रत्येक अक्षर को पढ़ना शुरू कर देते हैं, लेकिन अंततः हमारा मस्तिष्क किसी शब्द को पैटर्न के समूह के रूप में पहचानना शुरू कर देता है। यह बेहतर है अगर उन पैटर्न सुसंगत हैं। याद रखें कि ऊपरी मामले पत्र अक्सर निचले मामले से एक अलग पैटर्न होते हैं, और न केवल एक बड़ा संस्करण।
— एरोनल्स
1
लेकिन बहुत कम कीवर्ड हैं और वे बार-बार दिखाई देते हैं; मान्यता किसी भी समय के लिए SQL का उपयोग करने वाले किसी भी व्यक्ति के लिए समान रूप से तेज़ होनी चाहिए।
— केसी
3
सच है, यह निश्चित रूप से कुछ कठिन और तेज नहीं है। लेकिन कुछ ही खोजशब्द हैं जो बहुत सामान्य हैं। एक बड़ा सेट है जो कि नहीं है, और अक्सर लोग इस ऊपरी आवरण अभ्यास का विस्तार उन चीजों के लिए करते हैं जो बिलियन फ़ंक्शन हैं, लेकिन जरूरी नहीं कि सिंटैक्टिक भाषा कीवर्ड। व्यवहार में, मैं वास्तव में अभी भी चयन / डब्ल्यूएचईआर / ग्रुप जैसे कीवर्ड का एक छोटा सा ऊपरी हिस्सा हूं, जो किसी क्वेरी के एक प्रमुख खंड की शुरुआत का संकेत देता है। लेकिन इस तरह के अंतर्निहित कार्यों की तरह के रूप में अन्य सभी कीवर्ड, cast, rank, मैं लोअर केस।
— एरोनल्स
19

ऐसा इसलिए है क्योंकि SQL इतनी पुरानी भाषा ( 1974 ) है कि जब इसकी कल्पना की गई थी, तो अधिकांश कीबोर्ड में लोअरकेस अक्षर नहीं थे! भाषा के प्रलेखन ने उस समय की तकनीक को प्रतिबिंबित किया।

अनुसंधान ने साबित कर दिया है कि सभी CAPS पढ़ना कठिन है, इतना ही नहीं कि यूएसए फेडरल हाईवे एडमिनिस्ट्रेशन ने यूनिफ़ॉर्म ट्रैफ़िक कंट्रोल डिवाइसेस पर अपने मैनुअल में मिश्रित-केस संकेतों के उपयोग को अनिवार्य किया है, जिसमें कहा गया है:

पारंपरिक सड़क गाइड संकेतों पर स्थानों, सड़कों और राजमार्गों के नाम के लिए अक्षर प्रारंभिक अपरकेस अक्षरों के साथ लोअरकेस अक्षरों का एक संयोजन होगा।

न्यूयॉर्क पोस्ट भी प्रकाशित:

अध्ययनों से पता चला है कि ऑल-कैप्स संकेतों को पढ़ना कठिन है, और सड़क से दूर घूरने वाले उन अतिरिक्त मिलीसेकंड को दुर्घटनाओं की संभावना को बढ़ाने के लिए दिखाया गया है, खासकर पुराने ड्राइवरों के बीच।

अपरकेस अक्षरों का उपयोग करने का कोई अच्छा कारण नहीं है, और न करने के अच्छे कारण हैं।

मैं व्यक्तिगत रूप से SQL कीवर्ड के लिए अपरकेस का उपयोग कर घृणा करता हूं। मुझे इस दिन और उम्र में पढ़ना और बेतुका लगता है।

SQL भाषा को केस-असंवेदनशील होने के रूप में परिभाषित किया गया है। अपनी उंगली को उस शिफ्ट कुंजी से निकालो!

— बोहेमियन
स्रोत
3
मुझे लगता है कि अन्य उत्तरों में प्रस्तुत अच्छे कारणों की व्यापकता आपके दावे के खिलाफ बोलती है "अपरकेस अक्षरों का उपयोग करने का कोई अच्छा कारण नहीं है"।
— bignose
7
@bignose ओह कारण हैं ... मुझे नहीं लगता कि वे अच्छे हैं। मेरे अनुभव में, SQL प्रोग्रामर जितना अधिक जूनियर होता है, उतने ही अधिक वे अपरकेस का उपयोग करते हैं। इसके विपरीत, मैं एक सक्षम SQL कोडर से कभी नहीं मिला जो अपरकेस का उपयोग करता है।
— बोहेमियन
3
बिलकुल सहमत। अन्य "उत्तरों" की व्यापकता उन्हें सही नहीं बनाती है, यह सिर्फ उन्हें प्रचलित करती है। सभी उत्तरदाताओं को उन कंप्यूटरों से एक सूचना प्राप्त होती है जो कि उनके कीबोर्ड पर या उनके मामले के संदर्भ में मामले से संबंधित नहीं हैं। यह सिर्फ एक दिन है।
— चार्ल्स ब्रेटाना
हाँ और अपनी CAPS LOCK कुंजी को पहने या अपनी उंगलियों को Shift-कीज़ को अनावश्यक रूप से दबाए रखें।
— गॉर्डन बेल
9
मैं यहाँ परिपत्र तर्क गंध। यदि कारण को मामले के साथ भेदभाव करने वाले कीवर्ड के पक्ष में प्रस्तुत किया जाता है, तो आप इसे एक अच्छा कारण नहीं मानते हैं। यदि कारण SQL कोडर द्वारा प्रस्तुत किया गया है, लेकिन आपकी स्थिति से असहमत है, तो आप उन्हें सक्षम SQL कोडर नहीं होने के कारण खारिज कर देते हैं । मुझे लगता है कि इस आधार पर हम इसे अमान्य तर्क के रूप में खारिज कर सकते हैं।
— bignose
8

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

— ओविदियु पचुर
स्रोत
2
क्या क्वेरी संपादक और t-sql एकमात्र स्थान है जहाँ कोई भी आपका SQL कोड पढ़ रहा होगा? आपको कैसे मालूम?
— bignose
8

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

— dkretz
स्रोत
7

अपरकेस कम पठनीय है। सभी शब्दों की रूपरेखा बक्से के आकार की है; कोई अवरोही या आरोही नहीं हैं। लोवरकेस FTW!

— लांस फिशर
स्रोत
3
आपके द्वारा दिया जाने वाला कारण उस स्थिति का समर्थन करता है जो ऊपरी स्थिति बाकी के कीवर्ड को अलग करने में मदद करती है।
— bignose
5
@bignose यदि SQL मानव भाषा की तरह पढ़ता है, तो हमें अपरकेस की आवश्यकता क्यों है? हमें मानव भाषा में अपने क्रिया या प्रस्ताव को उच्चीकृत करने की आवश्यकता नहीं है। कल्पना कीजिए कि अगर कोई वाक्य इसे पसंद करता है। मुझे लगता है कि नियमित लेखन की तुलना में कम पठनीय है। उन दो वाक्यों में ऊपर दिए गए शब्द मेरे मस्तिष्क को रोकते हैं और उन्हें बाकी वाक्य की तुलना में धीमा कहते हैं, मेरे पढ़ने को धीमा कर देते हैं और प्रवाह को कम प्राकृतिक बना देते हैं।
— क्रिस मिडलटन
1
मानव भाषा वाक्य रचना में अस्पष्टता की बहुत क्षमा है। कंप्यूटर भाषाएं नहीं हैं, इसीलिए उन अस्पष्टताओं को कम से कम करने की आवश्यकता है। SQL सिंटैक्स उस के साथ मदद नहीं करता है, इसलिए हमें मानव को उपलब्ध उपकरणों का उपयोग करने की आवश्यकता है; SQL सिंटैक्स में बहुत कुछ नहीं होता है, इसलिए हमने कीवर्ड को कैपिटल करने की परंपरा विकसित की है।
— १
5

मुझे यह अधिक पठनीय लगता है। प्रत्येक खंड की शुरुआत के लिए एक नई पंक्ति होने और खंड के बीच इंडेंट करने के लिए समान।

— मार्क बोस्लेमैन
स्रोत
2

एक प्रारूपण उत्पाद आज़माएं (मैं Red Gate से SQL Prompt / SQL Refactor का उपयोग करता हूं)। आप यह सेट कर सकते हैं कि आप कैसे कैपिटलाइज़ेशन को काम करना चाहते हैं, और आपका कोड हमेशा लगातार स्वरूपित रहेगा। अपने पिंकी को आराम दें और कंप्यूटर को आपके लिए काम करने दें।

— gfrizzle
स्रोत
1
यह सलाह कई संदर्भों को अनदेखा करती है जहां SQL पढ़ा जा रहा है। यह पूरी तरह से किसी और द्वारा लिखित कोड पढ़ने के लिए अव्यावहारिक है; अगर इस तरह के एक उपकरण की जरूरत है तो केवल बुरी तरह से स्वरूपित SQL को पठनीय बनाने के लिए, यह इस प्रश्न द्वारा संबोधित एक सम्मेलन की तरह एक तर्क है।
— bignose
लेकिन यह दृष्टिकोण अच्छा है यदि आप अपने संगठन में मानक चाहते हैं। यदि आप मानक चाहते हैं, तो राय मायने नहीं
— रखती
2

पूंजीकरण का उपयोग जारी रखने का एक कारण यह है कि जब आप (या कोई और) नोटपैड जैसी किसी चीज में कोड देख रहे हैं, तो इसे पढ़ना आसान हो जाता है। यानी आप "कीवर्ड" और टैबलेन, एसपी, यूडीएफ आदि के बीच आसानी से अंतर कर सकते हैं

— CPU_BUSY
स्रोत
1

संप्रदायों के लिए अनुरूपता के अलावा, नहीं। यद्यपि यह एक बहुत ही व्यक्तिपरक विषय है, मैं सभी SQL के लिए मिश्रित मामले का उपयोग करना पसंद करता हूं। SQL पढ़ने में बहुत आसान है, और आधुनिक IDEs में कुछ भी नहीं खोया है जहाँ कीवर्ड सभी रंग-कोडित हैं।

— चार्ल्स ब्रेटाना
स्रोत
वहाँ: जैसा कि यहाँ कई अन्य उत्तर कारणों प्रस्तुत किया है, मुझे नहीं लगता कि आपका जवाब सही है कर रहे हैं कारणों "अनुरूपता की खातिर अनुरूप अलावा अन्य"।
— bignose
... तो फिर वे क्या हैं? हालाँकि, मैं हमेशा नई जानकारी के लिए खुला हूँ, लेकिन मुझे किसी के बारे में जानकारी नहीं है।
— चार्ल्स ब्रेटाना
मैंने पहले ही कई कारण बताए हैं , इसलिए अब आप जानते हैं।
— bignose
2
उनमें से कोई भी वैध कारण नहीं हैं, वे व्यक्तिगत प्राथमिकताएं हैं। बेझिझक अपनी व्यक्तिगत पसंद के अनुसार करें, लेकिन एक नियम या सर्वोत्तम अभ्यास के रूप में वरीयता को चिह्नित न करें।
— चार्ल्स ब्रेटाना
1

Microsoft SQL सर्वर प्रबंधन स्टूडियो में intellisense / autocompletion आरक्षित शब्दों के लिए ऊपरी या निचले मामले की अनुमति देता है, लेकिन ऊपरी मामलों में MAX (), SUM () जैसे फ़ंक्शन होते हैं।

फिर भी, पार्सर अभी भी अधिकतम () और सम () संसाधित करने के लिए कम केस संस्करणों की अनुमति देता है।

इसका अर्थ निष्पादन की प्रकृति के संबंध में एक अस्पष्टता है, और इसलिए यह केवल व्यक्तिगत प्राथमिकता का मामला है।

— बिल
स्रोत
4
हां, और SSMS में "विकल्प -> पाठ संपादक -> लेनदेन-एसक्यूएल -> गहन" आप चाहें तो डिफ़ॉल्ट को 'लोअर केस' में सेट कर सकते हैं।
— गॉर्डन बेल
0

मुझे सभी कैप्स में लिखा हुआ कुछ भी नापसंद है (और सभी कैप्स टाइप करने से भी ज्यादा नफरत है), लेकिन समुदाय के खिलाफ जाने के लिए खुद को मना नहीं सका। हमेशा की तरह विम और उससे जुड़े पैकेज इतनी सारी समस्याओं का हल हैं:

http://www.vim.org/scripts/script.php?script_id=305

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

— फर्डिनेंड वैन व्याक
स्रोत
-2

मैं अपने अधिकांश mySQL कोड को PHP के भीतर से कॉल करता हूं, और मैं अपने सभी PHP संपादन vim के भीतर करता हूं (या मुझे लगता है कि इस मामले में, VIM ;-)। अब मुझे यकीन है कि PHP के भीतर mySQL कोड को हाइलाइट करने के लिए प्लग इन हैं, लेकिन मुझे यह नहीं मिला है, और मुझे इसकी तलाश में जाने का समय नहीं है। इसलिए, मैं एलकैप में सब कुछ रखना पसंद करता हूं। मुझे यह मिल गया:

if ( !$bla ) 
{
   echo "select something from something where something";
}

if ( !$beepboop ) 
{
   echo "create table if not exists loremIpsum;
}

$query = "
CREATE TABLE IF NOT EXISTS HISTORY
(
   ID INT NOT NULL AUTO_INCREMENT,
   INSERTDATE TIMESTAMP DEFAULT NOW(),
   ALTERDATE TIMESTAMP(8) DEFAULT NOW(),
   DELETEDATE TIMESTAMP(8),
   ALTERCOUNT INT DEFAULT 0,
   SELECTCOUNT INT DEFAULT 0,

   PRIMARY KEY(ID),
)ENGINE=InnoDB
";

mysqlQuery( $query, $con );

PHP बनाम SQL के बीच अंतर करने में मेरी मदद करता है इससे बहुत बेहतर:

if ( !$bla ) 
{
   echo "select something from something where something";
}

if ( !$beepboop ) 
{
   echo "create table if not exists loremIpsum;
}

$query = "
create table if not exists history
(
   id int not null auto_increment,
   insertdate timestamp default now(),
   alterdate timestamp(8) default now(),
   deletedate timestamp(8),
   altercount int default 0,
   selectcount int default 0,

   primary key(id),
)engine=InnoDB
";

mysqlQuery( $query, $con );

इसके अलावा, किसी कारण के लिए, मुझे ऊंट के मामले के साथ मिश्रण करने से नफरत है, जैसे:

CREATE TABLE IF NOT EXISTS history
(
   ID INT NOT NULL AUTO_INCREMENT,
   insertDate TIMESTAMP DEFAULT NOW(),
   alterDate TIMESTAMP(8) DEFAULT NOW(),
   deleteDate TIMESTAMP(8),
   alterCount INT DEFAULT 0,
   selectCount INT DEFAULT 0,

   PRIMARY KEY(ID),
)ENGINE=InnoDB

वह IDमुझे परेशान करता है। इसके बजाय होना चाहिए id? या iD?

— PUK
स्रोत
3
नहीं, नहीं, नहीं, ऊंट चर नामों के लिए है, स्तंभ नामों के लिए नहीं। कॉलम नामों के लिए उचित मामले का उपयोग करें ... InsertDate, AlterDate, ...
— गॉर्डन बेल
1
SQL मानक को पहचानकर्ताओं में मामले को अनदेखा करने के लिए कार्यान्वयन की आवश्यकता होती है (यह उन्हें ऊपरी मामले में मोड़ देता है)। इसलिए आपका कोड पहचानकर्ताओं में मामले के अंतर पर निर्भर नहीं होना चाहिए, और ऐसा करने का पारंपरिक तरीका पहचानकर्ता बनाना है all_lower_case।
— bignose
3
@ बिग्नोस मैं अंडरस्कोर का बड़ा प्रशंसक नहीं हूं क्योंकि यह wpm कम हो जाता है
— puk
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.