क्या क्लॉज से इक्विटी में शामिल होना बेहतर है या जहां क्लॉज

Question

प्राथमिक कुंजी कॉलम पर दो साधारण तालिकाओं में शामिल होने और अतिरिक्त समानता स्थिति रखने पर यह स्वयं या जहां खंड में शामिल किया जा सकता है।

उदाहरण के लिए निम्नलिखित समतुल्य हैं। मेरा सवाल है - क्या एक शैली का उपयोग दूसरे पर करने का कोई कारण है?

SELECT * 
FROM A 
INNER JOIN B ON A.A_ID = B.A_ID 
      AND A.DURATION = 3.00 

... बनाम:

SELECT * 
FROM A 
INNER JOIN B ON A.A_ID = B.A_ID 
WHERE A.DURATION = 3.00 

Answer 1

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

---

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

Answer 2

इसकी शैली की बात। अनुकूलक सबसे अच्छा क्या करेगा।

Answer 3

SQL सर्वर 2000+ के लिए, इन प्रश्नों में से प्रत्येक के लिए क्वेरी योजना इंडेंटिकल होगी, और इसलिए प्रदर्शन भी होगा।

आप अपनी क्वेरी निष्पादित करने से पहले CTRL + M को मारने वाले प्रत्येक प्रश्न के लिए वास्तविक निष्पादन योजना प्रदर्शित करने के लिए एसएसएमएस का उपयोग करके इसे सत्यापित कर सकते हैं। परिणाम फलक में एक अतिरिक्त टैब होगा जो आपको निष्पादन योजना दिखाता है। आप देखेंगे कि इस मामले में, दो योजनाएं समान हैं।

Answer 4

यह महत्वपूर्ण बात है जो महत्वपूर्ण है।
कोई फर्क नहीं पड़ता, या तो प्रदान की गई क्वेरी का संस्करण उसी निष्पादन योजना का उपयोग करेगा क्योंकि आप एक इनर जॉइन से निपट रहे हैं।

तो एक बाहरी के साथ काम में शामिल हों (आईई: वाम, सही), वहाँ एक विशाल दो संस्करणों के बीच अंतर की वजह से WHERE मापदंड लागू किया जाता है के बाद शामिल हों बना है। यदि मानदंड ON खंड में निर्दिष्ट है, तो मानदंड लागू किया गया है जॉइन बनाया गया है जो परिणाम सेट के बीच काफी अंतर बना सकता है।

Answer 5

आम तौर पर यह कोई अर्थपूर्ण अंतर नहीं बनाता है।

एक किनारा मामला है जहां यह कर सकता है। यदि नीचे दिए गए अनुसार क्वेरी में GROUP BY ALL निर्माण जोड़ा गया है (बहिष्कृत)।

DECLARE @A TABLE(A_ID INT, DURATION DECIMAL(3,2)) 
INSERT INTO @A VALUES(1,2.00) 

DECLARE @B TABLE(A_ID INT) 
INSERT INTO @B VALUES(1) 

/*Returns one row*/ 
SELECT * 
FROM @A A 
INNER JOIN @B B ON A.A_ID = B.A_ID 
WHERE A.DURATION = 3.00 
GROUP BY ALL A.A_ID, A.DURATION, B.A_ID 

/*Returns zero rows*/  
SELECT * 
FROM @A A 
INNER JOIN @B B ON A.A_ID = B.A_ID AND A.DURATION = 3.00 
GROUP BY ALL A.A_ID, A.DURATION, B.A_ID 

Answer 6

--Samples for time of join wheather can we write condition at where or ON 
create table #emp(id int ,teamid int) 
create table #team(tid int,name char(2)) 
insert into #emp values(1,1) 
insert into #emp values(2,1) 
insert into #emp values(3,2) 
insert into #emp values(4,0) 

insert into #team values(1,'A') 
insert into #team values(2,'B') 
insert into #team values(3,'C') 

--select * from #emp 
--select * from #team 

--on inner join => there is no difference in Query Exc. Plan 
--select * from #emp e join #team t on e.teamid=t.tid where e.teamid=2 
--select * from #emp e join #team t on e.teamid=t.tid and e.teamid=2 


/*on outetr join see the differnence If dealing with an OUTER JOIN (IE: LEFT, RIGHT), 
there is a huge difference between the two versions because the WHERE criteria is applied after the JOIN is made. 
If the criteria is specified in the ON clause, the criteria is applied before the JOIN is made which can made a considerable difference 
between the result sets.*/ 
select * from #emp e left join #team t on e.teamid=t.tid 
select * from #emp e left join #team t on e.teamid=t.tid where e.teamid=2 
select * from #emp e left join #team t on e.teamid=t.tid and (e.teamid=2 or t.tid=1) and t.name='A' 


drop table #emp 
drop table #team