क्या WHERE क्लॉस और एक वास्तविक JOIN का उपयोग करके प्रश्नों के बीच कोई भौतिक अंतर है?

Question

में जानें एसक्यूएल हार्ड वे (व्यायाम छह) , लेखक प्रस्तुत निम्न क्वेरी:

SELECT pet.id, pet.name, pet.age, pet.dead
    FROM pet, person_pet, person
    WHERE
    pet.id = person_pet.pet_id AND
    person_pet.person_id = person.id AND
    person.first_name = "Zed";

और फिर कहते हैं कि:

"जॉइन्स" नामक काम करने के लिए वास्तव में इन प्रकार के प्रश्नों को प्राप्त करने के अन्य तरीके हैं। मैं अब उन अवधारणाओं से बच रहा हूं क्योंकि वे बहुत ही भ्रमित हैं। अभी के लिए तालिकाओं में शामिल होने के इस तरीके से चिपके रहें और उन लोगों को अनदेखा करें जो यह बताने की कोशिश करते हैं कि यह किसी तरह धीमा या "निम्न वर्ग" है।

क्या यह सच है? क्यों या क्यों नहीं?

Comments

मुझे नहीं लगता कि वहाँ है, लेकिन आप यह देखने के लिए कोई प्रयास कर सकते हैं कि क्वेरी निष्पादन में कोई अंतर है या नहीं।

— ग्रैंडमास्टरबी

मैं "हार्ड वे" शीर्षक के साथ एक अवधारणा को छोड़ते हुए एक काम के परस्पर विरोधी संकेतों को इंगित करना चाहता हूं "क्योंकि वे पागलपन से भ्रमित हैं"। लेकिन हो सकता है कि "कठिन रास्ता" होना चाहिए। लेकिन फिर, शायद नहीं।

— माइंडविन

बहुत अच्छी तरह से इरादे में शामिल हों (तालिकाओं में शामिल होने से) यह वास्तविक फिल्टर के लिए WHERE भाग को छोड़ देता है और इसे पढ़ना आसान बनाता है। (मौनी के अलावा अन्य निहितार्थ)

— Th 00

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

— डैनियल हॉलिनरेके

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

— मौरिस रीव्स

Answer 1

लेखक के दृष्टिकोण के साथ, OUTER JOINs को पढ़ाना बहुत अधिक कठिन है। INNER JOIN में ऑन क्लॉज अन्य सामानों की तरह मेरे लिए कभी भी बुरा नहीं था। शायद यह इसलिए है क्योंकि मैंने कभी पुराना तरीका नहीं सीखा। मुझे लगता है कि एक कारण है कि हम इससे छुटकारा पा चुके हैं और इसे स्मॉग नहीं होना चाहिए और इस पद्धति को निम्न वर्ग कहना चाहिए।

यह बहुत ही संकीर्ण परिदृश्य में सच है जिसे लेखक ने बनाया है:

• SQL का ऐसा एंट्री लेवल जो ON का उपयोग कर रहा है, जटिल है
• केवल JOIN / INNER JOIN पर विचार करें और किसी भी OUTER JOINs पर नहीं
• अलग-अलग कोडर जिन्हें दूसरे के कोड को पढ़ने की जरूरत नहीं है और न ही उनके कोड को पढ़ने / उपयोग करने के अनुभव वाले किसी भी व्यक्ति के पास है।
• बहुत सारी के साथ जटिल क्वेरी की आवश्यकता नहीं है: तालिकाओं, यदि है, लेकिन और या।

एक शिक्षण प्रगति के हिस्से के रूप में, मुझे लगता है कि इसे तोड़ना और प्राकृतिक प्रगति करना अधिक आसान है:

Select * from table
select this, something, that from table
select this from table where that = 'this'
select this from table join anothertable on this.id = that.thisid

तालिकाओं में शामिल होने और छानने की अवधारणा वास्तव में समान नहीं हैं। सही सिंटैक्स सीखने से अब अधिक कैरी-ओवर होगा जब आप OUTER JOINS सीखते हैं जब तक कि लेखक पुरानी / पदावनत चीजों को पढ़ाने का इरादा नहीं रखता: जैसे *= or =*।

Comments

JOIN स्टेटमेंट जोड़ा गया था क्योंकि बाहरी जोड़ को व्यक्त करने के लिए कोई मानक नहीं था, इसलिए प्रत्येक डेटाबेस विक्रेता के पास इसके लिए अपना "विशेष" (असंगत) सिंटैक्स था। IIRC ओरेकल था *=या =*यह दर्शाता है बाएं या दाएं बाहरी मिलती है, एक और एक मैं केवल बाईं बाहरी समर्थित इस्तेमाल एक का उपयोग कर मिलती |=ऑपरेटर।

— टीएमएन

@TMN IIRC Oracle का उपयोग किया गया +=या शायद यह था =+। मेरा मानना ​​है *=कि Transact-SQL (Sybase और बाद में MS-SQL) था। फिर भी, अच्छी बात है।

— डेविड

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

— डेविड

IIRC ऑपरेटरों जैसे "से अधिक" या "बराबर" को कभी-कभी "थीटा ऑपरेटरों" के रूप में संदर्भित किया जाता है, लेकिन एक Google खोज पथरी में कुछ ऑपरेशन की ओर जाता है।

— वाल्टर मिती

Answer 2

क्या यह धीमा है, यह क्वेरी ऑप्टिमाइज़र पर निर्भर करता है और यह क्वेरी को कैसे स्ट्रीम करता है (आप जो लिखते हैं वह वास्तव में निष्पादित नहीं होता है)। हालांकि, इस उद्धरण के साथ बड़ी समस्या यह है कि यह इस तथ्य को पूरी तरह से अनदेखा करता है कि विभिन्न प्रकार के जोड़ हैं जो पूरी तरह से अलग तरीके से संचालित होते हैं। उदाहरण के लिए, जो कहा जा रहा है वह (सैद्धांतिक रूप से) सही है inner joins, लेकिन यह outer joins( left joinsऔर right joins) के लिए सही नहीं है ।

Comments

+1 अन्य प्रकार के जॉइन के लिए। मेरे ज्यादातर जॉइन INNER JOINया तो हैं LEFT OUTER JOIN। वे "पागलपन से भ्रमित नहीं हैं।" एसक्यूएल पागलपन से भ्रमित हो सकता है, लेकिन यह इसका उदाहरण नहीं है।

— mgw854

ऑफ़ टॉपिक लेकिन स्टेटमेंट में शामिल होने के अलग-अलग प्रकार या एस के प्रकार होने चाहिए ?

— user1451111

Answer 3

लेखक एक साधारण मामला प्रस्तुत करता है जहां या तो पुराने या नए वाक्यविन्यास का उपयोग किया जा सकता है। मैं उनके / उनके बयान पर सहमत नहीं हूं जो जुड़ते हैं, वे पूरी तरह से भ्रमित हैं, क्योंकि तालिकाओं में शामिल होना एक मौलिक SQL क्वेरी अवधारणा है। इसलिए, शायद लेखक को यह बताने से पहले कुछ समय व्यतीत करना चाहिए था कि एक अलग-अलग तालिका क्वेरी उदाहरण के साथ-साथ एक रायपूर्ण कथन को बोलने से पहले JOINS कैसे काम करता है।

नए सिंटैक्स का उपयोग करना चाहिए। इसके लिए मुख्य तर्क यह है कि आपकी क्वेरी होगी:

• मानदंड चुनें
• मानदंड में शामिल हों
• फ़िल्टर मानदंड

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

फ़िल्टर क्लॉज में शामिल होने के मानदंड भूलकर भी कोई कार्टेशियन उत्पाद प्राप्त कर सकता है:

 person_pet.person_id = person.id

पुराने सिंटैक्स का उपयोग करना।

नए सिंटैक्स का उपयोग यह भी निर्दिष्ट करता है कि ज्वाइन कैसे होना चाहिए, जो इस बात पर महत्वपूर्ण है कि क्या आपको INNER, LEFT OUTER इत्यादि चाहिए, इसलिए यह JOIN सिंटैक्स के संबंध में अधिक स्पष्ट है जो IMHO उन तालमेल के साथ अपरिचित लोगों के लिए पठनीयता बढ़ाता है।

Answer 4

ऐसा नहीं होना चाहिए, क्वेरी पार्सर को समान प्रश्नों के लिए एक समान आंतरिक प्रतिनिधित्व उत्पन्न करना चाहिए, भले ही वे कैसे लिखे गए हों। लेखक का सिर्फ प्री-एसक्यूएल -92 सिंटैक्स का उपयोग करना है, यही कारण है कि वह उल्लेख करता है कि इसे "पुराने जमाने" या "निम्न वर्ग" के रूप में देखा जा सकता है। आंतरिक रूप से, पार्सर और ऑप्टिमाइज़र को एक ही क्वेरी योजना उत्पन्न करनी चाहिए।

Answer 5

मैंने SQL को इस तरह सीखा, जिसमें शामिल है *= बाहरी जोड़ के लिए सिंटैक्स शामिल है। मेरे लिए, यह बहुत सहज था क्योंकि सभी संबंधों को समान रूप दिया गया था और प्रश्नों की एक श्रृंखला के रूप में प्रश्नों को स्थापित करने का बेहतर काम किया था: आप क्या चाहते हैं? आप उन्हें कहाँ से चाहते हैं? आप कौन सा चाहते हैं?

ऐसा करने से joinवाक्य रचना है, यह संबंधों की दिशा में विचार प्रक्रिया और अधिक दृढ़ता से बाधित। और व्यक्तिगत रूप से, मुझे तालिकाओं और संबंधों के बीच के अंतर को कम पठनीय लगता है।

कम से कम MSSQL में, प्रश्नों के प्रदर्शन में कोई सार्थक अंतर नहीं है, यह मानते हुए कि आप उसी ज्वाइनिंग ऑर्डर का उपयोग करते हैं। उस ने कहा, इस तरह से सीखने (और उपयोग) SQL के साथ एक स्पष्ट, बहुत बड़ा मुद्दा है। यदि आप अपने संबंधों में से एक को भूल जाते हैं, तो आपको अप्रत्याशित क्रॉस-उत्पाद मिलेंगे। जो किसी भी गैर-तुच्छ आकार के डेटाबेस पर प्रतिबंधात्मक रूप से महंगा है (और गैर-चयन के लिए खतरनाक है!)। joinस्टाइल सिंटैक्स का उपयोग करते समय किसी रिश्ते को भूलना बहुत कठिन है ।

Comments

यह एक संबंधपरक डेटाबेस है, इसलिए संबंध क्वेरी के लिए बहुत महत्वपूर्ण हैं। मुझे व्यक्तिगत रूप से एक क्वेरी की समझ बनाने में बहुत मुश्किल है जो रिश्तों के साथ सच्चे फिल्टर (foo.x = 5) को मिलाता है (foo.x = bar.x)। इंजन इसे आसानी से एक में शामिल कर सकता है, लेकिन एक मानव को अनिवार्य रूप से इसके बारे में पंक्ति-दर-पंक्ति होना चाहिए, जैसा कि सेट और सबसेट के विपरीत है।

— हारून

Answer 6

विचार करने के लिए इसके दो अलग-अलग पहलू हैं: प्रदर्शन और रखरखाव / पठनीयता ।

रख-रखाव / पठनीयता

मैंने एक अलग क्वेरी चुनी, क्योंकि यह ऐसा कुछ है जो मुझे लगता है कि आपके द्वारा पोस्ट किए गए मूल प्रश्न से बेहतर / बदतर उदाहरण है।

आपके लिए क्या बेहतर है और अधिक पठनीय है?

select
    e.LoginID,
    DepartmentName = d.Name
from HumanResources.Employee e
inner join HumanResources.EmployeeDepartmentHistory edh
on e.BusinessEntityID = edh.BusinessEntityID
inner join HumanResources.Department d
on edh.DepartmentID = d.DepartmentID
where d.Name = 'Engineering';

या ...

select
    e.LoginID,
    DepartmentName = d.Name
from HumanResources.Employee e, 
HumanResources.EmployeeDepartmentHistory edh,
HumanResources.Department d
where e.BusinessEntityID = edh.BusinessEntityID
and edh.DepartmentID = d.DepartmentID
and d.Name = 'Engineering';

मेरे लिए व्यक्तिगत रूप से, पहला काफी पठनीय है। आप देखते हैं कि हम तालिकाओं के साथ जुड़ रहे हैं INNER JOIN, जिसका अर्थ है कि हम पंक्तियों को खींच रहे हैं जो बाद में शामिल होने वाले क्लॉज पर मेल खाते हैं (यानी "BusinessEntityID पर EmployeeDepboxHistory के साथ कर्मचारी शामिल हों और उन पंक्तियों को शामिल करें")।

उत्तरार्द्ध, अल्पविराम का मतलब मेरे लिए कुछ भी नहीं है। यह मुझे आश्चर्यचकित करता है कि आप उन सभी के साथ क्या कर रहे हैंWHERE उपवाक्यों के ।

पूर्व और अधिक पढ़ता है जैसे मेरा मस्तिष्क सोचता है। मैं हर दिन एसक्यूएल को देखता हूं और जुड़ने के लिए अल्पविराम। जो मुझे मेरे अगले बिंदु की ओर ले जाता है ...

"जॉइन" नामक काम करने के लिए वास्तव में इन प्रकार के प्रश्नों को प्राप्त करने के अन्य तरीके हैं

वे सभी जोड़ हैं। यहां तक ​​कि अल्पविराम भी शामिल है। तथ्य यह है कि लेखक उन्हें कॉल नहीं करता है जो वास्तव में उनका पतन है .... यह स्पष्ट नहीं है। यह स्पष्ट होना चाहिए। आप संबंधित डेटा जोड़ रहे हैं, चाहे आप निर्दिष्ट करेंJOIN या ,।

प्रदर्शन

यह निश्चित रूप से RDBMS-निर्भर होने जा रहा है। मैं केवल Microsoft SQL सर्वर की ओर से बोल सकता हूं। प्रदर्शन-वार ये समकक्ष हैं। आपको कैसे मालूम? निष्पादन के बाद की योजनाओं को कैप्चर करें और देखें कि इनमें से प्रत्येक कथन के लिए SQL सर्वर वास्तव में क्या कर रहा है:

उपरोक्त छवि में, मैंने हाइलाइट किया कि मैं दोनों प्रश्नों का उपयोग कर रहा हूं, केवल जुड़ने के लिए स्पष्ट वर्णों में भिन्न ( JOINबनाम ,)। SQL सर्वर ठीक यही काम करता है।

सारांश

अल्पविराम का उपयोग न करें। स्पष्ट JOINकथन का उपयोग करें ।

Comments

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

— रॉबर्ट हार्वे

बिंदु, यह सोचना है कि अल्पविराम विविधता संबंधपरक नहीं है, बिल्कुल सही नहीं है।

— थॉमस स्ट्रिंगर

मुझे लगता है कि आप गलत तरीके से अल्पविराम को जोड़ के रूप में व्याख्या कर रहे हैं। अल्पविराम केवल अलग-अलग टेबल हैं; यह कहाँ स्थितियाँ हैं जो जॉन्स बनाती हैं, कॉमा नहीं।

— रॉबर्ट हार्वे

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

— थॉमस स्ट्रिंगर

मैं कहूंगा कि पहले वाला बेहतर है क्योंकि आपके इरादे स्पष्ट हैं। बहुत कम अस्पष्टता है।

— डैनियल हॉलिनरेके

Answer 7

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

उनका उदाहरण एक पाठक को अपने अर्थ का एक मानसिक मानचित्र उत्पन्न करने के लिए प्रेरित करता है जिसमें बहुत अधिक अव्यवस्था होती है।

SELECT pet.id, pet.name, pet.age, pet.dead
    FROM pet, person_pet, person
    WHERE
    pet.id = person_pet.pet_id AND
    person_pet.person_id = person.id AND
    person.first_name = "Zed";

मोटे तौर पर, उपरोक्त है:

पालतू जानवरों की ID, NAME, AGE और DEAD को सभी पालतू जानवरों, person_pet, और उन व्यक्तियों के लिए प्राप्त करें जहाँ pet ID एक व्यक्ति_पेट के pet_id से मेल खाने के लिए होता है, और उस रिकॉर्ड का person_id उस व्यक्ति के व्यक्ति से मेल खाने के लिए होता है जिसका FIRST_NAME "Zed" है

इस तरह के एक मानसिक मानचित्र के साथ, पाठक (जो किसी कारण से हाथ से एसक्यूएल लिख रहा है) बहुत आसानी से गलती कर सकता है, संभवतः एक या अधिक तालिकाओं को छोड़ कर। और इस तरह से लिखे गए कोड के एक पाठक को कड़ी मेहनत करनी होगी, यह पता लगाने के लिए कि एसक्यूएल-लेखक क्या करने की कोशिश कर रहा है। ("हार्डर" वाक्यविन्यास-हाइलाइटिंग के साथ या बिना SQL पढ़ने के स्तर पर है, लेकिन यह अभी भी शून्य अंतर से अधिक है।)

एक कारण है कि जोइन आम क्यों हैं, और यह पुरानी क्लासिक "चिंताओं का पृथक्करण" है। विशेष रूप से, SQL क्वेरी के लिए यह पता लगाने का अच्छा कारण है कि डेटा कैसे संरचित है या डेटा कैसे फ़िल्टर किया जाता है।

यदि क्वेरी को क्लीनर लिखा गया है, जैसे कि

SELECT pet.id, pet.name, pet.age
FROM pet
  JOIN person_pet ON pet.id = person_pet.pet_id
  JOIN person ON person.id = person_pet.person_id
WHERE 
  person.first_name = "Zed";

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

---

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

Comments

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

— रॉबर्ट हार्वे

मैं यह देख सकता हूं, लेकिन लेखक केवल इस बात पर जोर नहीं दे रहा है कि वे एक सभ्य SQL सर्वर के बराबर बयान दे रहे हैं; वे जोर दे रहे हैं कि JOIN का उपयोग करना "भ्रमित करना" है, जो कि एक रास्ता है जो गंदा कोड प्रतीक्षा करता है। ("नहीं, LINQ का उपयोग न करें, बस अपना स्टेटमेंट हाथ से लिखें।" "कंपाइलर इस बात की परवाह नहीं करता है कि मैं इस विधि को क्या कहता हूं, इसलिए इसका कोई कारण नहीं है कि इसे

— FN1

Answer 8

आदमी एक क्लासिक त्रुटि कर रहा है। वह एक विशिष्ट कार्यान्वयन के साथ एक अमूर्त अवधारणा को सिखाने की कोशिश कर रहा है। जैसे ही आप ऐसा करते हैं कि आप इस तरह की गड़बड़ में आ जाते हैं।

पहले बुनियादी डेटाबेस अवधारणाओं को सिखाना चाहिए था, फिर उन्हें वर्णन करने के एक तरीके के रूप में SQL दिखाया गया।

बाएं और दाएं जुड़ जाते हैं, तर्क दिया जा सकता है कि वे बहुत ज्यादा मायने नहीं रखते हैं। आउटर जॉइन, अच्छी तरह से आप पुराने *=और उपयोग कर सकते हैं=* वाक्यविन्यास का ।

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

Comments

"लर्न एक्स द हार्ड वे" एक अलग सीखने का तरीका है। आप कोड लिखते हैं, और फिर बाद में इसे समझते हैं।

— रॉबर्ट हार्वे

@ रोबर्टहवे एक अलग सीखने का तरीका नहीं है, इसका मानक एक है। बाद में केवल तब होता है जब आप तब भी होते हैं जब पहिये बंद हो जाते हैं। जिस तरह से कई लोग SQL लिखते हैं, जो सोचते हैं कि एक तालिका कोशिकाओं का आयताकार सरणी है, इस पद्धति में कोई भी विश्वास है।

— टोनी हॉपकिंसन

Answer 9

उदाहरण आंतरिक JOINs के साथ सरल सुधार के बराबर है। यह अंतर पूरी तरह से अतिरिक्त संभावनाओं में निहित है जो कि JOIN सिंटैक्स अनुमति देता है। उदाहरण के लिए, आप उस क्रम को निर्दिष्ट कर सकते हैं जिसमें शामिल दो तालिकाओं के स्तंभ संसाधित होते हैं; देखें उदा https://stackoverflow.com/a/1018825/259310 ।

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

Comments

अच्छा जवाब, हालाँकि आप बयान WHEREमें क्लॉज़ का उपयोग करते हैं या JOINकरते हैं, वास्तव में क्वेरी ऑप्टिमाइज़र के आधार पर एक प्रदर्शन प्रभाव हो सकता है। मैंने देखा है कि यह एक से अधिक बार होता है।

— लोके

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

— माइकल पॉटर

Answer 10

जब मैंने SQL सीखा, तो INNER JOIN, LEFT JOIN, आदि फॉर्म मौजूद नहीं थे। जैसा कि अन्य उत्तर पहले ही बता चुके हैं, एसक्यूएल की विभिन्न बोलियों में से प्रत्येक में आइडिओसिंक्रोनिक सिंटैक्स का उपयोग करके बाहरी जोड़ लगाए गए थे। SQL कोड की यह क्षतिग्रस्त पोर्टेबिलिटी। भाषा को फिर से एक साथ लाने के लिए कुछ परिवर्तन की आवश्यकता थी, और LEFT JOIN, आदि जो वे पर बसे थे।

यह सच है कि हर INNER JOIN के लिए, WHERE क्लॉज में ज्वाइन कंडीशन के साथ बराबर कॉमा जॉइन किया जा सकता है। पुराने फॉर्म को पसंद करने से लेकर नए फॉर्म को पसंद करने के लिए माइग्रेट करने में मुझे थोड़ा वक्त लगा। जाहिर है, लर्निंग एसक्यूएल द हार्ड वे के लेखक अभी भी सोचते हैं कि पुराना तरीका आसान है।

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

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

तीसरा अंतर यह है कि जब आप INNER JOIN (या केवल सादे JOIN) का उपयोग करके सीखते हैं, तो LEFT JOIN, आदि सीखना आसान हो जाता है।

इसके अलावा कोई भी भौतिक अंतर नहीं है।

Answer 11

यह निर्भर करता है कि क्या आप सेट और औपचारिक तर्क के संदर्भ में सोचते हैं ....।

यदि आप ऐसा करते हैं तो औपचारिक तर्क से एसक्यूएल में अधिक सरल प्रगति के लिए "जॉइन" कीवर्ड का उपयोग नहीं करता है।

लेकिन अगर 99% लोगों को पसंद है, तो आपने अपने गणित की डिग्री में औपचारिक तर्क का आनंद नहीं लिया है, तो सम्मिलित कीवर्ड सीखने में आसान है। औपचारिक तर्क प्रश्नों को लिखने के लिए एसक्यूएल विश्वविद्यालय में एसक्यूएल के रूप में प्रस्तुत किया जाता था ....