इस SQL ​​स्टेटमेंट में डबल इनर जॉइन का उपयोग करने का कारण क्या है?

Question

मैं इस विरासत SQL क्वेरी को देख रहा हूं। जो बिट मुझे नहीं मिल पा रहा है, वह यह है कि यह एक ही कॉलम पर दो बार एक ही टेबल से इनरिंग क्यों कर रहा है। मैं टेबल 1 के बारे में बात कर रहा हूं और टेबल 1 उर्फ ​​"टेबल 1 एलियास" के साथ शामिल हो गया है,

SELECT DISTINCT othercolumns,
                Table1Alias.columna
FROM   maintable
       INNER JOIN secondarytable
               ON maintable.id1 = secondarytable.a_id1
       INNER JOIN table1
               ON secondarytable.id2 = table1.id3
       INNER JOIN table1 Table1Alias
               ON secondarytable.id2 = Table1Alias.id3
       INNER JOIN thirdtable
               ON table1.id4 = thirdtable.id5
       INNER JOIN fourthtable
               ON thirdtable.id6 = fourthtable.id7
       INNER JOIN fivetable
               ON thirdtable.id8 = fivetable.id9
       INNER JOIN sixthtable
               ON Table1Alias.columna = sixthtable.id10
       LEFT JOIN seventhtable
              ON thirdtable.id11 = seventhtable.id12
WHERE  LEFT(secondarytable.type123, 2) BETWEEN '01' AND '09'
       AND secondarytable.type456 = 'cate'
       AND table1.type = '0'
       AND Table1Alias.columna = 'conn'

Comments

एक स्व के लिए क्या है? (अंग्रेजी में)

— दीक्षा २४'१ phil

Answer 1

यह इस तरह से क्वेरी को फिर से लिखने में मदद कर सकता है, इसलिए यह स्पष्ट है कि 2 जोड़ अलग हैं , यानी जोड़ अलग-अलग सबसेट (एक ही तालिका के) हैं:

FROM   maintable 
       INNER JOIN secondarytable 
               ON maintable.id1 = secondarytable.a_id1 
       INNER JOIN table1 
               ON secondarytable.id2 = table1.id3 
              AND table1.type = '0' 
       INNER JOIN table1 Table1Alias 
               ON secondarytable.id2 = Table1Alias.id3 
              AND Table1Alias.columna = 'conn' 
       INNER JOIN
       ...
WHERE  LEFT(secondarytable.type123, 2) BETWEEN '01' AND '09' 
       AND secondarytable.type456 = 'cate' 

Comments

जॉइन्ट में शामिल होने के लिए WH WHES नहीं है, अर्थात मैं सहमत हूँ कि क्या उन बाधाओं को ज्वाइन स्टेटमेंट का हिस्सा था, अर्थात AND द्वारा कनेक्ट किया गया था, लेकिन WHERE सभी अनुभव में ज्वाइन फ़िल्टरिंग पंक्तियों के परिणाम पर लागू होता है ज्वाइन टेबल, वास्तविक ज्वाइन को प्रभावित नहीं करना।

— फ्रैंक हॉपकिंस

@Darkwing जहाँ तक मुझे पता है, इससे कोई फर्क नहीं पड़ता कि आपने कहाँ शर्तें रखी हैं, क्योंकि यह क्वेरी ऑप्टिमाइज़र का काम है, जो बेहतरीन एक्सर्साइज़ प्लान के साथ आता है। हालाँकि यह बेहतर है कि उन्हें अगले जोड़ के रूप में रखा जाए क्योंकि यह उन्हें और अधिक पठनीय बनाता है लेकिन यह सिर्फ एक राय है

— गणित

यहां तक ​​कि अगर ऐसा होना भी था तो जॉइंट्स के परिणाम में शामिल होने के बाद अंत में अलग-अलग होते हैं। और हां, जुड़ने वाली पंक्तियों को आमतौर पर जुड़ने से पहले फ़िल्टर किया जाता है क्योंकि यह प्रदर्शन में सुधार करता है।

— घुर्मण

यह भी एक उपश्रेणी के साथ जुड़ने के बराबर है, उदा INNER JOIN (SELECT * FROM table1 WHERE type = 0) table1। यह और भी स्पष्ट हो सकता है कि क्या हो रहा है।

— बरमार

@मैटमैटिक्स - चाहे कोई स्थिति ONजॉइन के क्लॉज में हो या WHEREक्लॉज में, अगर जॉइन की है तो यह बहुत बड़ी बात हो सकती है OUTER JOIN। यदि ONक्लॉज में कोई शर्त विफल हो जाती है , तो प्राथमिक पंक्ति अभी भी शामिल है (एक मिलान बाहरी पंक्ति के बिना); यदि यह WHEREखंड में विफल रहता है , तो प्राथमिक पंक्ति को परिणाम सेट से बाहर रखा गया है।

— RDFozz

Answer 2

whereखण्ड को देखते हुए , जिस पंक्ति को इंगित किया जा रहा है, उसके table1लिए कॉलम type= '0' की आवश्यकता होती है और जिस पंक्ति को इंगित किया जा रहा है, table1aliasउसके लिए कॉलम columnaको = 'कॉन' की आवश्यकता होती है ।

शायद table1उसी के लिए कई पंक्तियाँ हैं id3?

Answer 3

तालिका संरचना को देखे बिना - दृष्टिकोण एक छोटे गैर-आवरण सूचकांक का उपयोग करने के लिए हो सकता है और फिर एक 'प्रमुख लुकअप' ऑपरेशन से बचने के लिए और मौजूदा अनुक्रमित को संशोधित करने से बचने के लिए पंक्तियों के शेष पाने के लिए एक बड़े कवरिंग इंडेक्स पर तालिका में शामिल हो सकता है। (या यदि आप अनुक्रमित को संशोधित नहीं कर सकते हैं)

Answer 4

जब भी किसी कॉम्प्लेक्स जॉइन में एक से अधिक बार टेबल दिखाई देती है, तो यह आमतौर पर होता है क्योंकि एक इकाई है जो एक से अधिक संबंधों में भाग लेती है। @Ypercube ने जो उत्तर दिया है, उसे देखते हुए यह मामला यहाँ प्रतीत होता है।

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

तालिका 1 जैसे तालिका नामों के साथ, हमें इस बारे में कोई सुराग नहीं मिला है कि आपका विषय कैसे काम करता है। और यहां तक ​​कि अगर नाम वर्णनात्मक थे, तो आपके सिस्टम की विषय वस्तु के बारे में हमारी समझ आपके मामले में आवश्यक से बहुत भिन्न हो सकती है। यह आप पर निर्भर होने वाला है।