SQL ANSI-92 से बेहतर मानक ANSI-89 क्यों नहीं अपनाया गया है?

Question

मैंने जिस भी कंपनी में काम किया है, मैंने पाया है कि लोग अभी भी ANSI-89 मानक में अपने SQL क्वेरी लिख रहे हैं:

select a.id, b.id, b.address_1
from person a, address b
where a.id = b.id

एएनएसआई -92 मानक के बजाय:

select a.id, b.id, b.address_1
from person a
inner join address b
on a.id = b.id

इस तरह की एक बहुत ही सरल क्वेरी के लिए, पठनीयता में कोई बड़ा अंतर नहीं है, लेकिन बड़े प्रश्नों के लिए मुझे पता चलता है कि टेबल से बाहर सूचीबद्ध करने के लिए मेरे जॉइन मानदंड में समूहबद्ध होने से यह देखना बहुत आसान हो जाता है कि मेरे जॉइन में कहां समस्या हो सकती है, और मुझे अपने सभी फ़िल्टरिंग को अपने WHERE क्लॉज़ में रखने दें। यह उल्लेख करने के लिए नहीं कि मुझे लगता है कि ओरेकल में (+) सिंटैक्स की तुलना में बाहरी जोड़ बहुत सहज हैं।

जैसा कि मैं लोगों को ANSI-92 को प्रचारित करने की कोशिश करता हूं, क्या ANSI-89 का ANSI-89 का उपयोग करने में कोई ठोस प्रदर्शन लाभ है? मैं इसे अपने दम पर आजमाऊंगा, लेकिन हमारे पास जो ओरेकल सेटअप है, वह हमें EXPLAIN PLAN का उपयोग करने की अनुमति नहीं देता है - क्या लोग नहीं चाहेंगे कि वे अपने कोड को ऑप्टिमाइज़ करने की कोशिश करें, फिर करेंगे?

Comments

SQL-92 में शामिल होने का एक प्रमुख लाभ यह है कि LEFT OUTER JOIN और वेरिएंट लिखने का एक मानक और अपेक्षाकृत सरल तरीका है। प्रत्येक DBMS का अपना भिन्न वाक्य-विन्यास होता था (आमतौर पर बुरा; वास्तव में, मुझे लगता है, अपवाद के बिना नोटेशन खराब थे) और अक्सर थोड़े अलग शब्दार्थ के साथ। SQL-92 ने तय किया है, और नया अंकन केवल उन आधारों पर उपयोग करने के लायक है। मुझे लगता है कि यह वैसे भी स्पष्ट है, एक बार जब आप इसे करने के लिए उपयोग किया जाता है। इसका उपयोग करने में थोड़ा समय लगता है, लेकिन यह कठिन नहीं है, और एक बार परिवर्तित हो जाने के बाद वापस नहीं जाना है।

— जोनाथन लेफ्लर

अर्थ-शास्त्र, किन्नर, किन्नर-विरोधी!

— सैम

मैं यहाँ पार्टी के लिए देर से एक सा है, लेकिन कोई नहीं बताया है करने के लिए ओरेकल खुद को दिखाई देती है कि अनुशंसा करता है कि FROM खंड की बाहरी का उपयोग नहीं बल्कि ओरेकल से वाक्य रचना में शामिल हों ऑपरेटर में शामिल होने के

— bornfromanegg

मैंने एक नया उत्तर जोड़ा है जो बहुत अधिक अद्यतित है और सीधा है, उत्तर में अन्य भ्रांतियों पर स्पष्टता के साथ यहां stackoverflow.com/a/47720615/124486

— इवान कैरोल

Answer 1

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

मैं SQL-92 सिंटैक्स को भी प्रचारित करने की कोशिश करता हूं। मंजूर होने के सोलह साल बाद, यह समय लोगों का उपयोग करना शुरू कर रहा है! और SQL डेटाबेस के सभी ब्रांड अब इसका समर्थन करते हैं, इसलिए गैर-मानक (+)ओरेकल सिंटैक्स या *=Microsoft / सिम्बियन सिंटैक्स का उपयोग जारी रखने का कोई कारण नहीं है ।

जैसे कि SQL -89 की आदत के डेवलपर समुदाय को तोड़ना इतना कठिन है, मैं केवल यह मान सकता हूं कि प्रोग्रामर्स के एक बड़े "आधार का आधार" है, जो किताबों, पत्रिका लेखों से प्राचीन उदाहरणों का उपयोग करके कॉपी और पेस्ट करके कोड करते हैं, या दूसरा कोड आधार, और ये लोग नए वाक्यविन्यास को सार रूप से नहीं सीखते हैं। कुछ लोग पैटर्न-मैच करते हैं, और कुछ लोग रटे द्वारा सीखते हैं।

मैं धीरे-धीरे लोगों को एसक्यूएल -92 सिंटैक्स का उपयोग करते हुए देख रहा हूं, हालांकि मैं जितना इस्तेमाल करता था, उससे कहीं अधिक बार। मैं 1994 से SQL प्रश्नों का ऑनलाइन उत्तर दे रहा हूं।

Comments

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

— टोनी एंड्रयूज

सहमत हैं, लेकिन जोड़ते हैं कि अच्छी तरह से प्रलेखित परिदृश्य हैं जहां पुराने ANSI-89 सिंटैक्स में गलत परिणाम उत्पन्न होते हैं ... विशेष रूप से बाहरी जॉइन होते हैं जब शामिल होने के "बाहरी" पक्ष से गैर-ज्वाइन संबंधित स्तंभों पर सशर्त फ़िल्टरिंग की भविष्यवाणी होती है।

— चार्ल्स ब्रेटाना

मैं एमएस एसक्यूएल के विशिष्ट आंतरिकों को नहीं जानता, लेकिन यह अच्छा प्रमाण है कि एसक्यूएल -92 सिंटैक्स सार्थक है। मेरे लिये कार्य करता है!

— बिल कार्विन

बड़े पैमाने पर? कृपया अपना काम पोस्ट करें। मेरी सबसे अच्छी शर्त यह है कि यह सेब की तुलना करने के लिए एक सेब नहीं है, लेकिन "ओह हाँ यह है" के साथ प्रतिक्रिया न करें "बस एक परीक्षण के मामले में हम पुन: पेश, संस्करण, पैच स्तर आदि के साथ जवाब दे सकते हैं

इसके अलावा, "उपाख्यान" प्रमाण वैसे भी वैज्ञानिक उपाय नहीं है। इसे हमेशा नमक के दाने के साथ लिया जाता है।

— बिल कार्विन

Answer 2

खैर ANSI092 मानक में कुछ सुंदर जघन्य वाक्यविन्यास शामिल हैं। नेचुरल जॉइन एक हैं और USING क्लॉज एक और। IMHO, एक तालिका के लिए एक स्तंभ के अलावा कोड को नहीं तोड़ना चाहिए लेकिन एक प्राकृतिक रूप से सबसे अधिक आकर्षक फैशन में टूट जाता है। ब्रेक करने का "सबसे अच्छा" तरीका संकलन त्रुटि से है। उदाहरण के लिए यदि आप * कहीं का चयन करते हैं, तो एक कॉलम जोड़ सकते हैंसंकलन करने में विफल। असफल होने का अगला सबसे अच्छा तरीका रन टाइम एरर होगा। यह बदतर है क्योंकि आपके उपयोगकर्ता इसे देख सकते हैं, लेकिन यह अभी भी आपको एक अच्छी चेतावनी देता है कि आपने कुछ तोड़ दिया है। यदि आप ANSI92 का उपयोग करते हैं और NATURAL के साथ प्रश्न लिखते हैं, तो यह संकलन समय पर नहीं टूटेगा और यह रन टाइम पर नहीं टूटेगा, क्वेरी बस अचानक गलत परिणाम उत्पन्न करना शुरू कर देगी। इस प्रकार के कीड़े कपटी होते हैं। रिपोर्टें गलत हैं, संभावित वित्तीय प्रकटीकरण गलत हैं।

प्राकृतिक जोड़ों के साथ अपरिचित लोगों के लिए। वे हर स्तंभ के नाम पर दो तालिकाओं से जुड़ते हैं जो दोनों तालिकाओं में मौजूद हैं। जब आपके पास 4 कॉलम कुंजी है और आप इसे टाइप करने से बीमार हैं तो यह वास्तव में अच्छा है। समस्या तब आती है जब Table1 में DESCRIPTION नाम का एक पूर्व-मौजूदा कॉलम होता है और आप Table2 नाम से एक नया कॉलम जोड़ते हैं, ओह, मुझे नहीं पता, कुछ सहज जैसा, mmm, DESCRIPTION और अब आप एक VARCHAR2 पर दो तालिकाओं में शामिल हो रहे हैं (१०००) क्षेत्र जो मुक्त रूप है।

ऊपर वर्णित समस्या के अलावा USING क्लॉज कुल अस्पष्टता का कारण बन सकता है। एक अन्य SO पोस्ट में , किसी ने यह ANSI-92 SQL दिखाया और इसे पढ़ने में मदद मांगी।

SELECT c.* 
FROM companies AS c 
JOIN users AS u USING(companyid) 
JOIN jobs AS j USING(userid) 
JOIN useraccounts AS us USING(userid) 
WHERE j.jobid = 123

यह पूरी तरह से अस्पष्ट है। मैंने दोनों कंपनियों और उपयोगकर्ता तालिकाओं में एक उपयोगकर्ता नाम कॉलम रखा है और कोई शिकायत नहीं है। क्या होगा यदि कंपनियों में यूजरआईडी कॉलम उस पंक्ति को संशोधित करने के लिए अंतिम व्यक्ति की आईडी है?

मैं गंभीर हूं, क्या कोई समझा सकता है कि इस तरह की अस्पष्टता क्यों जरूरी थी? इसे सीधे मानक में क्यों बनाया गया है?

मुझे लगता है कि बिल सही है कि डेवलपर का एक बड़ा आधार है जो कोडिंग के माध्यम से वहां कॉपी / पेस्ट करते हैं। वास्तव में, मैं स्वीकार कर सकता हूं कि जब मैं एएनएसआई -92 की बात करता हूं तो मैं एक तरह का हूं। हर उदाहरण मैंने कभी देखा कि कई जोड़ियाँ कोष्ठकों में निहित हैं। ईमानदारी, कि सबसे अच्छा में कठिन वर्ग में तालिकाओं को बाहर निकालना। लेकिन तब एक SQL92 evangilist ने समझाया कि वास्तव में शामिल होने के आदेश को मजबूर करेगा। यीशु ... उन सभी कॉपी पेस्टर्स को मैंने देखा है जो अब वास्तव में एक ज्वाइनिंग ऑर्डर के लिए मजबूर कर रहे हैं - एक काम जो 95% समय बेहतर होता है, जो कि ऑप्टिमाइज़र के लिए विशेष रूप से कॉपी / पेस्टर है।

उनके कहने पर तोमलक ने ठीक कहा,

लोग नए सिंटैक्स पर स्विच नहीं करते हैं क्योंकि यह वहां है

यह मुझे कुछ देना है और मैं एक उल्टा नहीं देखता हूं। और अगर कोई उल्टा है, तो नकारात्मक को नजरअंदाज किया जा सकता है।

Comments

मैं ON का उपयोग इसलिए करता हूं क्योंकि यह USING या NATURAL JOIN से कम अस्पष्ट है। कोष्ठक के रूप में, जो लोग Microsoft Access पर "SQL" सीखते हैं, यदि आप उन्हें छोड़ देते हैं तो एक्सेस व्हाइन्स के रूप में उपयोग करेगा। (एसक्यूएल के आस-पास के भाव उंगली के उद्धरण होने चाहिए।)

— पॉवरलॉर्ड

खाँसी क्या एक प्रयोग का खंड है? ;-) मैं SQL सर्वर अंश से आता हूं, इसलिए यह वास्तव में मेरे रडार पर नहीं है। जैसा कि आर। बेमरोज़ ने कहा, ऑन क्लॉज़ है, बस ठीक काम कर रहा है, मुझे कभी भी एक ऐसे जोड़ के साथ नहीं छोड़ रहा है जिसे मैं वाक्यात्मक रूप से व्यक्त नहीं कर सकता। कुछ टाइपिंग को सहेजने के लिए मेरे DB डिज़ाइन को क्वेरी सिंटैक्स में अनुकूलित करने की आवश्यकता नहीं है।

— तोमलक

यदि आपको अपना डेटा अच्छी तरह से पता नहीं है कि उपयुक्त होने पर NATURAL JOIN या USING का उपयोग करें, तो आपको शायद इसके लिए SQL नहीं लिखना चाहिए। -1 अज्ञानता के लिए।

— रॉब

IMHO, प्राकृतिक जुड़ाव उसी थैली में गिरता है SELECT *(तब ग्राहक को पता चलता है कि वह फील्ड ऑर्डर पर निर्भर है) - यह सिर्फ थोड़ा सा टेढ़ा लगता है

— बेसिक

प्राकृतिक जोड़ो के साथ आप जिस समस्या का वर्णन करते हैं वह आपके डेटाबेस डिजाइन के साथ एक समस्या है - मानक के साथ एक नहीं। आपको अपने डेटा के बारे में पता होना चाहिए, और कॉलम नामों के लिए मानक स्थापित किए होंगे।

— ट्रैविस

Answer 3

कुछ कारण दिमाग में आते हैं:

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

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

Comments

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

— बिल कार्विन

हम्म ... मुझे यहां तक ​​कि जटिल नियमित अभिव्यक्तियों को देखकर भी कोई दुख नहीं हुआ। एसक्यूएल मुझे नुकसान नहीं पहुंचा सकता। ;-)

— टॉमालक

"शुरुआती में अक्सर समस्याएं होती हैं ..." वैसे भी एक विक्रय बिंदु है

किसी कारण के लिए मुझे यकीन नहीं है कि अगर वह "समर्थक" या "गर्भनिरोधक" टिप्पणी थी ... हो सकता है कि मेरा विडंबना डिटेक्टर टूट गया हो।

— टॉमालक

Answer 4

ऊपर से प्राकृतिक जॉय और उपयोग पोस्ट के जवाब में।

आप कभी भी इनका उपयोग करने की आवश्यकता क्यों देखेंगे - वे ANSI-89 में उपलब्ध नहीं थे और ANSI-92 के लिए जोड़े गए थे जो मैं केवल एक शॉर्टकट के रूप में देख सकता हूं।

मैं कभी भी इसमें शामिल होने का मौका नहीं छोड़ूंगा और हमेशा टेबल / उपनाम और आईडी निर्दिष्ट करूंगा।

मेरे लिए, जाने का एकमात्र तरीका ANSI-92 है। यह अधिक क्रिया है और वाक्यविन्यास ANSI-89 अनुयायियों द्वारा पसंद नहीं किया जाता है, लेकिन यह बड़े करीने से आपके फ़िल्टरिंग से आपके JOINS को अलग करता है।

Comments

मैं एक प्राकृतिक के रूप में प्राकृतिक दृश्यों को नहीं देखता, लेकिन एक संबंधपरक DB के भीतर ऑब्जेक्ट ओरिएंटेड DB प्रोग्रामिंग में एक Segway।

— आर्मंड

Answer 5

पहले मुझे यह कहना चाहिए कि SQL सर्वर में बाहरी सिंटैक्स (* =) हर समय सही परिणाम नहीं देता है। ऐसे समय होते हैं जब यह व्याख्या करता है कि एक क्रॉस जॉइन होता है न कि एक बाहरी जॉइन। तो सही इसका उपयोग बंद करने का एक अच्छा कारण है। और वह बाहरी जोड़ सिंटैक्स एक पदावनत विशेषता है और SQL सर्वर 2008 के बाद SQL सर्वर के अगले संस्करण में नहीं होगा। आप अभी भी आंतरिक जुड़ाव करने में सक्षम होंगे लेकिन पृथ्वी पर कोई भी क्यों करना चाहेगा? वे अस्पष्ट हैं और बनाए रखने के लिए बहुत कठिन हैं। आप आसानी से नहीं जानते कि जुड़ने का हिस्सा क्या है और वास्तव में सिर्फ क्लॉज कहां है।

एक कारण है कि मेरा मानना ​​है कि आपको पुराने वाक्यविन्यास का उपयोग नहीं करना चाहिए वह यह है कि समझ जुड़ती है और वे जो करते हैं और जो नहीं करते हैं वह SQL कोड लिखने वाले किसी भी व्यक्ति के लिए एक महत्वपूर्ण कदम है। आपको अच्छी तरह से समझे बिना किसी भी SQL कोड को नहीं लिखना चाहिए। यदि आप उन्हें अच्छी तरह से समझते हैं, तो आप संभवतः इस निष्कर्ष पर पहुंचेंगे कि ANSI-92 सिंटैक्स स्पष्ट और बनाए रखने में आसान है। मैं एक SQL विशेषज्ञ से कभी नहीं मिला हूं जो पुराने वाक्य रचना के लिए ANSI-92 सिंटैक्स का उपयोग नहीं करता है।

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

Comments

आपसे मिलकर बहुत खुशी हुई। आपका पहला होना मुबारक हो।

Answer 6

मुझे स्कूल में ANSI-89 पढ़ाया गया और कुछ वर्षों तक उद्योग में काम किया। फिर मैंने 8 साल के लिए DBMS की शानदार दुनिया छोड़ दी। लेकिन फिर मैं वापस आ गया और इस नए ANSI 92 सामान को पढ़ाया जा रहा था। मैंने सिंटैक्स पर ज्वाइन सीख लिया है और अब मैं वास्तव में एसक्यूएल सिखाता हूं और मैं नए जॉइन सिंटैक्स पर सलाह देता हूं।

लेकिन जो नकारात्मक पहलू मुझे दिखता है वह है सहसंबंधित उपश्रेणियाँ ANSI 92 के प्रकाश के प्रकाश में समझ में नहीं आती हैं। जब ज्वाइन की जानकारी WHERE में शामिल की गई थी और सहसंबद्ध उपश्रेणियों को "ज्वाइन" किया गया था, तो सभी सही और सुसंगत लग रहे थे। ANSI में 92 टेबल ज्वाइन मानदंड WHERE और सबक्वेरी में नहीं है "ज्वाइन" है, वाक्यविन्यास असंगत लगता है। दूसरी ओर, इस असंगति को "ठीक" करने की कोशिश शायद इसे और बदतर बना देगी।

Comments

दूसरी ओर, आप पी [रब्बी shoudl को परस्पर सम्बन्धित उपश्रेणियाँ नहीं लिख रहे हैं क्योंकि वे विकृत होज हैं। वे आपकी क्वेरी में एक कर्सर डालने की तरह हैं। ओह।

— HLGEM

Answer 7

मुझे यकीन है कि इसका जवाब नहीं पता है .. यह एक धार्मिक युद्ध है (मैक-पीसी या अन्य की तुलना में कम डिग्री की अल्बाइट)

एक अनुमान यह है कि हाल ही में जब तक ओरेकल, (और शायद अन्य विक्रेताओं के रूप में) ने एएनएसआई -92 मानक को नहीं अपनाया था (मुझे लगता है कि यह ओरेकल v9, या उपचार में था) और इसलिए, डीबीए / डीबी डेवलपर्स के लिए जो कंपनियों में काम कर रहे हैं अभी भी इन संस्करणों का उपयोग कर रहे थे, (या चाहते थे कि कोड उन सर्वरों पर पोर्टेबल हो जो इन संस्करणों का उपयोग कर रहे हों, उन्हें पुराने मानक पर ही टिकना था ...

यह वास्तव में शर्म की बात है, क्योंकि नई ज्वाइन सिंटैक्स बहुत अधिक पठनीय है, और पुराना सिंटैक्स कई अच्छी तरह से प्रलेखित परिदृश्यों में गलत (गलत) परिणाम उत्पन्न करता है।

• विशेष रूप से, बाहरी जोड़ तब होते हैं जब सशर्त फ़िल्टरिंग गैर-ज्वाइन संबंधित स्तंभों पर तालिका के "बाहरी" किनारे पर तालिका से गैर-सम्मिलित होते हैं।

Comments

हाँ, ओरेकल 9 आई; 2001 में जारी किया गया। पार्टी के लिए थोड़ी देर!

MS SQL INNER JOIN1995 में जोड़ा गया, हालांकि LEFT JOIN1996 तक नहीं। MySQL ने कम से कम 3.23 के बाद से इसका समर्थन किया, 1999 में जारी किया गया; PostgreSQL कम से कम 7.2 के बाद से, 2002 में जारी किया गया। कुछ आकस्मिक Googling ने मुझे Teradata के लिए कोई जवाब नहीं दिया।

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

— डेविड

Answer 8

जड़ता और व्यावहारिकता।

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

एसक्यूएल लिखना मेरे काम का लगभग 10% है। अगर मुझे एक समस्या के समाधान के लिए ANSI-92 SQL की आवश्यकता है जो ANSI-89 SQL हल नहीं कर सकता है तो मैं इसका उपयोग करूँगा। (मैं इसे एक्सेस में उपयोग करता हूं, वास्तव में।) यदि हर समय इसका उपयोग करने से मुझे अपनी मौजूदा समस्याओं को बहुत तेजी से हल करने में मदद मिलेगी, तो मैं इसे आत्मसात करने के लिए समय व्यतीत करूंगा। लेकिन मैं वाक्यविन्यास के बारे में कभी सोचे बिना ANSI-89 SQL को कोड़ा मार सकता हूं। मुझे समस्याओं को हल करने के लिए भुगतान मिलता है - SQL सिंटैक्स के बारे में सोचना मेरे समय और मेरे नियोक्ता के पैसे की बर्बादी है।

किसी दिन, युवा ग्रासहॉपर, आप एएनएसआई -92 एसक्यूएल सिंटैक्स के अपने उपयोग का बचाव करते हुए युवा लोगों के खिलाफ कहेंगे कि आपको एसक्यू 3 (या जो भी) का उपयोग करना चाहिए। और तब तुम समझ सकोगे। :-)

Comments

यहां वर्णित दृष्टिकोण, विचार के स्कूल को "इसे ठीक करें जब यह टूट जाता है" जैसे एक बहुत लगता है, तो निवारक रखरखाव के विचार से बचना। आपको समस्याओं को हल करने के लिए भुगतान किया जाता है, हां, लेकिन आपको अपनी कंपनी को अधिक मूल्य प्रदान करने के लिए भी भुगतान किया जाता है। आपके मामले में ANSI-89 शॉर्ट टर्म में अधिक मूल्य प्रदान करता है, लेकिन लंबे समय में ANSI-92 में निवेश का समय अधिक महंगा विकल्प नहीं होगा।

— ट्रैविस

आपके द्वारा किए गए कार्यों से चिपके रहने की वजह से गरीब व्यक्ति के लिए एक लागत आती है जो आपके पास जाने पर आपके कोड को बनाए रखने के लिए होती है। इसका मतलब यह नहीं है कि आपको महीने के स्वाद पर स्विच करना चाहिए, लेकिन सर्वोत्तम प्रथाओं को अपनाने से लगभग हमेशा स्थिरता में भुगतान करना होगा।

मैं एक्सेल में नहीं जाऊँगा (जहाँ आप माउस या उससे कम के तीन क्लिक्स में कुछ भी कर सकते हैं), क्योंकि मैंने हज़ारों लोटस 123 कमांड्स को कंठस्थ कर लिया है जिनकी मुझे आवश्यकता है और मैं उनका उपयोग करने में सहज हूं! हा!

— चार्ल्स ब्रेटाना

Answer 9

मेरे पास एक क्वेरी थी जो मूल रूप से SQL Server 6.5 के लिए लिखी गई थी, जो SQL 92 सिंटैक्स में शामिल होने का समर्थन नहीं करती थी, अर्थात

select foo.baz
from foo
  left outer join bar
  on foo.a = bar.a

इसके बजाय के रूप में लिखा गया था

select foo.baz
from foo, bar
where foo.a *= bar.a

क्वेरी कुछ समय के लिए आसपास रही थी, और संबंधित डेटा क्वेरी को बहुत धीमा चलाने के लिए जमा हुआ था, जिसे पूरा करने के लिए 90 सेकंड का समय था। जब यह समस्या उत्पन्न हुई, तब तक हम SQL Server 7 में अपग्रेड हो चुके थे।

अनुक्रमणिका और अन्य ईस्टर-एगिंग के साथ mucking के बाद, मैंने SQL 92 के अनुरूप होने के लिए सिंटैक्स को बदल दिया। क्वेरी समय 3 सेकंड तक गिरा।

स्विच करने का एक अच्छा कारण है।

यहां से रेपोस्ट किया गया ।

Answer 10

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

ठीक है, वास्तव में, मैं पहले रूप को अधिक सहज पाता हूं, जिससे दोनों तालिकाओं के बीच कोई स्पष्ट पदानुक्रम नहीं है। तथ्य यह है कि मैंने एसक्यूएल को संभवतः पुरानी पुस्तकों के साथ सीखा था, पहला रूप दिखा रहा है, शायद मदद नहीं करता ... ;-)
और पहला संदर्भ मुझे Google में एक sql चुनिंदा खोज पर मिला है (जो मेरे लिए ज्यादातर फ्रेंच उत्तर देता है ... ) पहले पुराने रूप को दिखाता है (फिर दूसरे को समझाता है)।

बस "क्यों" प्रश्न पर कुछ संकेत देते हुए ... ^ _ ^ मुझे इस विषय पर एक अच्छी, आधुनिक पुस्तक (डीबी अज्ञेयवादी) पढ़ना चाहिए। अगर किसी के पास सुझाव हैं ...

Answer 11

मैं सभी स्कूलों के लिए नहीं बोल सकता लेकिन मेरे विश्वविद्यालय में जब हम अपने पाठ्यक्रम के एसक्यूएल मॉड्यूल कर रहे थे, तो उन्होंने एएनएसआई -92 नहीं पढ़ाया, उन्होंने एएनएसआई -89 सिखाया - उस पर एक पुरानी वैक्स प्रणाली! मैं ANSI-92 के संपर्क में नहीं था, जब तक कि मैंने एक्सेस में चारों ओर खुदाई शुरू नहीं की, क्वेरी डिज़ाइनर का उपयोग करके कुछ प्रश्न बनाए और फिर SQL कोड में खुदाई की। यह महसूस करते हुए कि मुझे पता नहीं था कि यह कैसे जोड़ रहा था, या सिंटैक्स के निहितार्थ मैंने गहराई से खोदना शुरू कर दिया ताकि मैं इसे समझ सकूं।

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

बेशक, ऐसे तकनीकी प्रचारक हैं जो टिंकर को पसंद करते हैं और समझते हैं और यह उन प्रकारों को दर्शाता है जो "नए" सिद्धांतों को अपनाते हैं और बाकी को बदलने की कोशिश करते हैं।

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

बेशक, यह सिर्फ मेरे अनुभव के आधार पर मेरी राय है।

Comments

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

— बिल करविन

किसी को कुछ सफल से अलग करने के लिए किसी को समझाने के लिए उसे समझाने के लिए कठिन है, जो कोई लाभ नहीं देता है। घर का हमारा .net पक्ष 1.0 से 3.5 तक बदल गया है और ZERO cajoling के साथ प्रत्येक चरण। प्रत्येक नया संस्करण बेहतर था। यहाँ एक ही नहीं कह सकते।

Answer 12

1) OUTER JOIN, बनाम * = या (+) = लिखने का मानक तरीका

2) प्राकृतिक जोइन

3) डेटाबेस इंजन, ANSI-92 ट्रेंड में और अधिक अनुकूल होने के लिए निर्भर हैं।

4) मैनुअल अनुकूलन:

मान लीजिए कि हमारे पास अगला सिंटैक्स है (ANSI-89):

(1)select * from TABLE_OFFICES to,BIG_TABLE_USERS btu
where to.iduser=tbu.iduser and to.idoffice=1

इसे इस प्रकार लिखा जा सकता है:

(2)select * from TABLE_OFFICES to
inner join BIG_TABLE_USERS btu on to.iduser=tbu.iduser
where to.idoffice=1

लेकिन यह भी:

(3)select * from TABLE_OFFICES to
inner join BIG_TABLE_USERS btu on to.iduser=tbu.iduser and to.idoffice=1

उनमें से सभी (1), (2), (3) एक ही परिणाम लौटाते हैं, हालांकि वे अलग-अलग रूप से अनुकूलित होते हैं, यह डेटाबेस इंजन में निर्भर करता है, लेकिन उनमें से अधिकांश करते हैं:

• (1) डेटाबेस इंजन तक इसका अनुकूलन तय करता है।
• (2) यह दोनों तालिकाओं को मिलाता है फिर प्रति कार्यालय फ़िल्टर करें।
• (3) यह BIG_TABLE_USERS को आइडॉफिस का उपयोग करके फ़िल्टर करता है और फिर दोनों तालिकाओं में शामिल हो जाता है।

5) लंबे समय तक प्रश्न कम गड़बड़ हैं।

Answer 13

पुराने और युवा प्रोग्रामर और प्रशिक्षुओं और नए स्नातकों के साथ मेरे व्यावहारिक अनुभव के कारण लोग ANSI-89 का उपयोग करते हैं:

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

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

Answer 14

यहां SQL-89, और SQL-92 की तुलना करते हुए कुछ बिंदु दिए गए हैं और अन्य उत्तरों में कुछ गलत धारणाओं को दूर कर रहे हैं।

1. NATURAL JOINSएक भयानक विचार है। वे अंतर्निहित हैं और उन्हें तालिका के बारे में मेटा-जानकारी की आवश्यकता है। SQL-92 के बारे में कुछ भी उनके उपयोग की आवश्यकता नहीं है इसलिए बस उन्हें अनदेखा करें । वे इस चर्चा के लिए प्रासंगिक नहीं हैं।
2. USING एक महान विचार है, इसके दो प्रभाव हैं:
   1. यह एक समभुज से निर्धारित परिणाम पर केवल एक कॉलम बनाता है।
   2. यह एक ध्वनि और समझदार सम्मेलन है। SQL-89 में आपके पास idदोनों तालिकाओं पर कॉलम लिखने वाले लोग थे । आपके द्वारा तालिकाओं में शामिल हो जाने के बाद, यह अस्पष्ट और अस्पष्ट हो जाता है और इसके लिए स्पष्ट अलियासिंग की आवश्यकता होती है। इसके अलावा, idशामिल होने पर लगभग निश्चित रूप से अलग डेटा था। यदि आप किसी व्यक्ति को कंपनी में शामिल करते हैं, तो आपको अब एक idसे एक person_id, और एक idसे company_id, जिसके बिना जुड़ने से दो अस्पष्ट कॉलम बनेंगे। तालिका की सरोगेट कुंजी के लिए विश्व स्तर पर विशिष्ट पहचानकर्ता का उपयोग करना, इस सम्मेलन का मानक पुरस्कार है USING।
3. SQL-89 सिंटैक्स एक निहित है CROSS JOIN। ए CROSS JOINसेट को कम नहीं करता है, यह स्पष्ट रूप से इसे बढ़ता है। FROM T1,T2के रूप में ही है FROM T1 CROSS JOIN T2, कि कार्टेशियन में शामिल होने का उत्पादन होता है जो आमतौर पर वह नहीं है जो आप चाहते हैं। दूर की WHEREस्थिति से हटाए जाने के लिए चयनात्मकता होने का मतलब है कि आप डिजाइन के दौरान गलतियां करने की अधिक संभावना रखते हैं।
4. एसक्यूएल -89 ,और एसक्यूएल -92 स्पष्ट JOINएस में अलग - अलग मिसाल है। JOINएक उच्च मिसाल है। इससे भी बदतर, कुछ डेटाबेस जैसे MySQL बहुत लंबे समय के लिए गलत हो गया। । इसलिए दो शैलियों का मिश्रण एक बुरा विचार है, और आज की सबसे लोकप्रिय शैली SQL-92 शैली है।

Comments

1) यदि आप संबंधपरक मॉडल का अध्ययन करते हैं, तो आप इस बात की सराहना करेंगे कि कोई भी स्वाभाविक रूप से एक महान विचार में शामिल नहीं होता है, यह केवल एक ही प्रकार का जुड़ाव है। 2) 1 देखें अर्थात आवश्यकता नहीं है। 3) सिंटैक्स (और दोनों SQL-92 सिंटैक्स हैं ) के बावजूद , रिलेशनल ऑपरेटर उत्पाद (गुणा) है, यानी वास्तव में एक ज्वाइन (कार्टेसियन जॉइन) भी नहीं है)। 4. 1 देखें अर्थात आवश्यकता नहीं है।

— onedaywhen

Answer 15

ओरेकल एएनएसआई -92 को अच्छी तरह से लागू नहीं करता है। मेरे पास कई समस्याएं हैं, कम से कम नहीं है क्योंकि Oracle Apps में डेटा टेबल बहुत अच्छी तरह से कॉलम के साथ संपन्न हैं। यदि आपके जॉइन में कॉलमों की संख्या लगभग 1050 कॉलम से अधिक है (जो कि Apps में करना बहुत आसान है), तो आपको यह शानदार त्रुटि मिलेगी जो बिल्कुल तार्किक समझ में नहीं आती है:

ORA-01445: cannot select ROWID from a join view without a key-preserved table.

पुरानी शैली में शामिल होने के लिए वाक्यविन्यास को फिर से लिखने के लिए क्वेरी को फिर से लिखना समस्या को गायब कर देता है, जो एएनएसआई -92 के कार्यान्वयन में दोष की उंगली को इंगित करता है।

जब तक मुझे इस समस्या का सामना नहीं करना पड़ा, मैं ASNI-92 का एक स्थिर प्रवर्तक था, क्योंकि एक आकस्मिक क्रॉस जॉइन के अवसर को कम करने में लाभ के कारण, जो कि पुरानी शैली के सिंटैक्स के साथ करना बहुत आसान है।

अब, हालाँकि, मुझे इस पर ज़ोर देना ज़्यादा मुश्किल लगता है। वे ओरेकल के खराब क्रियान्वयन की ओर इशारा करते हैं और कहते हैं "हम इसे अपने तरीके से करेंगे, धन्यवाद।"

Comments

क्रॉस जॉइन करना आसान हो सकता है, यह भी कुछ ऐसा है जो अनायास नहीं होता है और यह निश्चित रूप से अस्पष्ट नहीं है। कोई भी सभ्य SQL डेवलपर इसे देख सकता है। लेकिन USING और NATURAL JOIN प्रलोभन हैं जो आपको पुकारते हैं और आपकी छोटी नाव को पीड़ा और दुख की चट्टानों पर तोड़ते हैं।

मेरा कहना था, जहां दो खंड एक साथ जुड़ते हैं, वहां से गायब होकर एक आकस्मिक क्रॉस सफलतापूर्वक सफलतापूर्वक बनाना आसान है। ANSI-92 में एक क्रॉस जॉइन जानबूझकर किया जाना है। लेकिन मैं इस बात से सहमत हूं कि नेचुरल जॉइन एक घृणा है। :)

— जोनाथन

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

Answer 16

एक नया SQL मानक पिछले मानक, उर्फ ​​'अनुकूलता के बंधनों' से सब कुछ प्राप्त करता है। तो 'पुराना' / 'अल्पविराम से अलग' / 'अयोग्य' शामिल होने की शैली पूरी तरह से मान्य SQL-92 है।

अब, मैं तर्क देता हूं कि एसक्यूएल -92 NATURAL JOINएकमात्र ऐसा जरिया है जिसकी आपको जरूरत है। उदाहरण के लिए, मैं तर्क देता हूं कि यह श्रेष्ठ है inner joinक्योंकि यह डुप्लिकेट कॉलम उत्पन्न नहीं करता है - स्तंभों SELECTको खंडित करने के लिए क्लॉस में अधिक रेंज चर नहीं ! लेकिन मैं हर दिल और दिमाग को बदलने की उम्मीद नहीं कर सकता हूं, इसलिए मुझे कोडर्स के साथ काम करने की आवश्यकता है, जो कि मैं व्यक्तिगत रूप से विरासत में शामिल होने वाली शैलियों को अपनाना जारी रखूंगा (और वे रेंज वेरिएबल्स को 'उपनाम' भी कह सकते हैं!)। यह टीम वर्क की प्रकृति है और वैक्यूम में काम नहीं करता है।

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