2010-04-16 7 views
8
SELECT * FROM TableA 
INNER JOIN TableB 
ON TableA.name = TableB.name 

SELECT * FROM TableA, TableB 
where TableA.name = TableB.name 

पसंदीदा तरीका कौन सा है और क्यों? जब जॉइन जैसे कीवर्ड का उपयोग किया जाता है तो क्या कोई प्रदर्शन अंतर होगा?इनर जॉइन कीवर्ड | उन्हें उपयोग किए बिना और

धन्यवाद

उत्तर

11

दूसरा तरीका join कीवर्ड से पहले, इसे करने का शास्त्रीय तरीका है।

आम तौर पर क्वेरी प्रोसेसर दो क्वेरी से समान डेटाबेस संचालन उत्पन्न करता है, इसलिए प्रदर्शन में कोई अंतर नहीं होगा।

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

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

+0

सहमत है, पहला स्पष्टता और नियंत्रण के लिए बेहतर है; यदि आप चाहते हैं तो जॉइन प्रकार को बदलना आसान है। –

1

EXPLAIN SELECT …

यह प्रयोग किया जाता इंजन पर निर्भर करता है का उपयोग करते हुए, क्वेरी अनुकूलक पर, कुंजी पर मेज पर, द्वारा पता लगाना; काफी सब कुछ पर

3

, पहले एक का उपयोग के रूप में यह है:

  • अधिक स्पष्ट
  • स्टैंडर्ड रास्ता

प्रदर्शन के लिए के रूप में है - कोई फर्क नहीं होना चाहिए।

+2

यह आपको फिल्टर स्थितियों (WHERE खंड में) से जुड़ने की स्थिति (ऑन क्लॉज में) को अलग करने देता है –

0

अधिकांश वर्तमान डेटाबेस उन दोनों प्रश्नों को सटीक उसी निष्पादन योजना में अनुकूलित करेंगे। हालांकि, पहले वाक्यविन्यास का उपयोग करें, यह वर्तमान मानक है। इस वाक्यविन्यास में शामिल होने और उपयोग करके, यह LEFT OUTER JOIN और RIGHT OUTER JOIN के साथ क्वेरी करने पर सहायता करेगा। जो WHERE खंड में शामिल होने के साथ पुराने वाक्यविन्यास का उपयोग करके मुश्किल और समस्याग्रस्त हो जाता है।

+0

मैंने पाया है कि एक उचित सामान्यीकृत डेटाबेस में सही शामिल होना चाहिए (कभी भी?) एक denormalized डेटाबेस में, यह हमेशा सच नहीं है। मैं इसे सामान्यीकरण/संरचना को दोबारा करने के लिए एक उपाय की आवश्यकता के रूप में उपयोग करता हूं। –

+0

@ मार्क Schultheiss, इस सवाल को देखें: http://stackoverflow.com/questions/689963/does-anyone-use-right-outer-joins –

+0

बिल्कुल, केवल तालिका अनुक्रम को बदलने से बाएं जुड़ने में सही अधिकार होगा, जो रखरखाव चक्रों में मेरे अनुभव से आसान है, खासकर जूनियर डेवलपर्स –

1

कुछ एसक्यूएल इंजनों में दूसरा फॉर्म (सहयोगी जॉइन) को वंचित कर दिया गया है। पहले फॉर्म का प्रयोग करें।

दूसरा कम स्पष्ट है, कोड लिखते समय SQL को विघटन करने के लिए भिखारी का कारण बनता है। WHERE क्लॉज अनुक्रम से मेल खाने के लिए मिलान मैच आवश्यकता के अनुक्रम के कारण जटिल एसक्यूएल में प्रबंधन करना बहुत मुश्किल है - वे (कोड में घुमाव) से मेल खाना चाहिए या लौटाए गए परिणाम बदले गए डेटा सेट परिवर्तन को बदल देंगे जो वास्तव में इसके खिलाफ जाता है सोचा कि अनुक्रम को परिणामों को तब नहीं बदला जाना चाहिए जब समान स्तर पर तत्वों पर विचार किया जाता है।

जब एकाधिक तालिकाओं वाले जॉइन बनते हैं, तो यह दूसरे रूप का उपयोग करके काफी तेज़ कोड को प्राप्त करना मुश्किल हो जाता है।

संपादित करें: प्रदर्शन: मैं व्यक्तिगत प्रदर्शन के आसानी से कोडिंग, डिबगिंग को आसान बनाने पर विचार करता हूं, इस प्रकार संपादन/डीबग/रखरखाव में आसानी पहले प्रदर्शन का उपयोग करके बेहतर प्रदर्शन करने वाला है - यह मुझे विकास के दौरान सामान को समझने/समझने में कम समय लेता है और रखरखाव चक्र।

+1

के लिए बस स्पष्ट होने के लिए, बाएं और दाएं के रूप में चित्रित फॉर्म '* =' और '= *' है, जो टेबल के लिए अलग एएनएसआई मानक अल्पविराम नहीं है। .. अगर मैं उस भाग से भ्रम जोड़ता हूं तो क्षमा करें :) –

0

फ़िल्टरिंग पूरी तरह से WHERE का उपयोग करके जुड़ती है कुछ सामान्य परिदृश्यों में बेहद अक्षम हो सकती है।उदाहरण के लिए:

SELECT * FROM people p, companies c WHERE p.companyID = c.id AND p.firstName = 'Daniel' 

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

एक बेहतर तरीका उन जोड़ों के साथ बाधाओं को समूहित करना है जहां प्रासंगिक हैं। यह न केवल पढ़ने के लिए विषयपरक आसान है बल्कि यह भी अधिक कुशल है। Thusly:

SELECT * FROM people p JOIN companies c ON p.companyID = c.id 
    WHERE p.firstName = 'Daniel' 

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

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

संबंधित मुद्दे