लेफ्ट जॉय पर राइट जॉय पसंद करने का कारण


18

अगर मैं सही ढंग से समझूं, हर RIGHT JOIN:

SELECT Persons.*, Orders.*
FROM Orders
RIGHT JOIN Persons ON Orders.PersonID = Persons.ID

के रूप में व्यक्त किया जा सकता है LEFT JOIN:

SELECT Persons.*, Orders.*
FROM Persons
LEFT JOIN Orders ON Persons.ID = Orders.PersonID

मेरी निजी राय है कि वक्तव्य का आशय:

  • पहले मिलता है Persons
  • फिर विस्तार करें / Personsमैच के लिए आवश्यक रूप से दोहराएंOrders

Persons LEFT JOIN Ordersरिवर्स- ऑर्डर की तुलना में बेहतर ऑर्डर द्वारा व्यक्त किया गया है Orders RIGHT JOIN Persons(और RIGHT JOINपरिणामस्वरूप मैं कभी उपयोग नहीं करता)।

क्या ऐसी कोई स्थितियाँ हैं जहाँ एक RIGHT JOINको प्राथमिकता दी जाती है? या, क्या कोई उपयोग के मामले RIGHT JOINहैं जो ऐसा कुछ कर सकते हैं जो LEFT JOINनहीं कर सकते हैं?


12
मुझे एक मामला याद नहीं आ रहा है जहाँ मैं एक सही जॉइन चाहता था। मेरे पास ऐसे मामले हैं जहां एक क्वेरी की निष्पादन योजना बाईं ओर से जुड़ने के लिए प्रदर्शन के कारणों के लिए दाईं ओर मिलती है। लेकिन एक शुद्ध कोड लिखने के दृष्टिकोण से, नहीं, मुझे याद नहीं है कि एक सही जुड़ाव लिखना।
ब्रैंडन

2
मैं इसे "समझाने, लिखने या डिबगिंग कोड" के बारे में एक प्रश्न के रूप में नहीं देखता हूं। यह पूछ रहा है कि एक भाषा में दो विशेषताएं क्यों होती हैं जो स्पष्ट रूप से एक ही काम करती हैं, अगर वास्तव में उनके बीच कोई अंतर है, और यदि नहीं तो "गैर-स्पष्ट" एक को प्राथमिकता दी जाएगी।
फिलिप केंडल

1
नहीं, एक लेफ्ट जॉइन लगभग हमेशा कब्जा करता है कि आपको सबसे ज्यादा जरूरत क्या है और इसके बारे में तर्क करना आसान है। मेरे कार्यस्थल पर, हमारे पास वास्तव में दाएं जोड़ों को रोकने के लिए एक मानक है क्योंकि ऐसा कोई मामला नहीं है जहां वे आवश्यक हैं (यानी उन्हें हमेशा विपरीत बाईं ओर से बदला जा सकता है)।
mgw854

8
मैंने करीबी वोटों को रीसेट कर दिया है - यह सवाल यहां विषय पर है, क्योंकि जॉन्स के बीच अंतर को समझना सॉफ्टवेयर डिजाइन को प्रभावित करता है (डेटाबेस डिजाइन सॉफ्टवेयर डिजाइन का हिस्सा है, क्योंकि एल्गोरिदम क्वेरी डेटाबेस हो सकते हैं)। यह डेटाबेस व्यवस्थापकों पर भी विषय पर हो सकता है, और वहाँ भी एक डुप्लिकेट हो सकता है।
थॉमस ओवेन्स

1
मुझे यकीन नहीं है कि आप सुझाव दे रहे हैं कि RIGHT JOINसिफारिश की गई है या अधिक सामान्य है। यदि वह आपका आधार है, तो यह गलत है। मैं उस समय के बारे में नहीं सोच सकता, जिसे मैंने कभी भी सही कोड में या न ही उदाहरणों में इस्तेमाल किया हो। यह JOINया है LEFT OUTER JOIN। दुर्लभ मामलों में आप देख सकते हैं a FULL OUTER JOIN
जिमीजैम

जवाबों:


12

यह इस बात पर निर्भर करता है कि आप किस आवश्यकता को पूरा करने की कोशिश कर रहे हैं।

यह कहने के लिए समान नहीं है: "सभी व्यक्तियों और उनके संगत आदेशों को गिने" कि "मुझे उनके संबंधित व्यक्तियों के साथ सभी आदेश चाहिए" , खासकर यदि आप is nullबिना किसी संबंधित मैच के पंक्तियों को लाने के लिए उपयोग करने जा रहे हैं । यही कारण है कि मैं "प्रमुख तालिका" कहता हूं, जो तालिका है जिसमें मैं शामिल होने के दूसरे पक्ष में एक संक्षिप्त पंक्ति नहीं होने के बावजूद पंक्तियों को प्राप्त करना चाहता हूं।

इस चित्र को देखें और आप देखेंगे कि वे समान नहीं हैं:

यहाँ छवि विवरण दर्ज करें

छवि का स्रोत यह उत्कृष्ट लेख है

लेकिन आप सही हैं कि दोनों आवश्यकताओं को पूरा किया जा सकता है या तो बस में शामिल होने में तालिकाओं के क्रम में शामिल हों।

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

तो एक सही जुड़ाव पसंद करने का एक संभावित कारण यह है कि आपकी संस्कृति में आप दाईं से बाईं ओर लिखते हैं (जैसे अरबी या हिब्रू लेखन प्रणाली में) और आप इस तरह से सोचते हैं, जिसका अर्थ है कि शायद आपके मस्तिष्क में पाठीय जानकारी दाईं से बाईं ओर बहती है ।

कुछ भाषाविदों को लगता है कि आपकी भाषा आपके सोचने के तरीके को प्रभावित करती है: https://www.edge.org/conversation/lera_boroditsky-how-does-our-language-shape-the-way-we-think


1
मैंने इन पंक्तियों के साथ सोचना शुरू कर दिया था, लेकिन मुझे नहीं लगता कि यह सही है। मैंने हिब्रू में एसक्यूएल लिखने की कल्पना करना शुरू कर दिया (जो मैंने वास्तव में कभी नहीं किया है)। ओके: राइट जस्टिफ़ाइड, राइट-टू-लेफ्ट, टॉप-डाउन। आप अभी भी तालिका ए पहले तो तालिका बी का उल्लेख करेंगे एक सही सम्मिलित होने के साथ, आप तब (विशेषकर अशक्त स्थिति में) सबसे पहले या पहले उल्लेखित तालिका के सभी को बाहर कर देंगे। मुझे लगता है कि मानव मन पहले प्राथमिक और सबसे महत्वपूर्ण के साथ जुड़ जाता है । यह लेखन दिशा की परवाह किए बिना होता है। आप उन्हें "FIRST JOIN" और "SECOND JOIN" कह सकते हैं और यह पूर्वाग्रह अभी भी घटित होगा।
माइक

मैंने नीचे दिखाई गई छवि का लिंक शामिल किया है।
जॉन रेन्नोर

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

अब मैंने छवि के निर्माता को उचित श्रेय दिया। मैं इसे अपने HD में वर्षों के लिए था और मुझे याद नहीं था कि यह कहाँ से आया था,
Tulains Córdova

मैं हिब्रू में धाराप्रवाह हूं और मुझे अभी भी LEFT JOINअधिक प्राकृतिक लगता है ।
ज़ेव स्पिट्ज

3

ऐसा कुछ भी नहीं है (जो मुझे पता है) कि दाएं हाथ से काम किया जा सकता है जो बाएं हाथ से नहीं किया जा सकता है। लेकिन कभी-कभी बाएं जोड़ों के साथ वाक्य रचना बदसूरत होती है। मान लें कि आपके पास निम्नलिखित तालिकाएँ हैं:

Persons
ID | Name

Orders
ID | CustomerId | other unimportant stuff

SpecialOrderDetails
ID | OrderId | other stuff

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

select p.*, o.*, d.*
from Persons p
left join Orders o on o.CustomerId = p.Id
inner join SpecialOrderDetails d on d.OrderId = o.Id

तो आप इसे इस रूप में फिर से लिख सकते हैं:

--get all the people without a special order
select p.*, NULL, NULL, ... --NULLs placeholders for all the fields from OrderDetails and SpecialOrderDetails
from Persons p
left join Orders o on o.CustomerId = p.Id
left join SpecialOrderDetails d on d.OrderId = o.Id
where o.Id is null 

union

--get all the people with a special order
select p.*, o.*, d.*
from Persons p
inner join Orders o on o.CustomerId = p.Id
inner join SpecialOrderDetails d on d.OrderId = o.Id

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

select p.*, o.*, d.*
from Orders o
inner join SpecialOrderDetails d on d.OrderId = o.Id
right join Persons p on p.Id = o.CustomerId

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

select p.*, o.*, d.*
from Persons p
left join Orders o 
    inner join SpecialOrderDetails d on d.OrderId = o.Id
on o.CustomerId = p.Id

इस बिंदु पर, यह एक विकल्प है कि क्या सबसे स्पष्ट है और अधिकांश लोग क्या समझेंगे (क्या आप जानेंगे कि उस वाक्यविन्यास को कैसे Google करें यदि आपको नहीं पता था कि इसे नेस्टेड जॉइन कहा जाता है?)।

संक्षेप में, आप सख्ती नहीं करते सही जुड़ने की आवश्यकता , लेकिन वे इसे पढ़ना आसान बना सकते हैं।


मुझे लगता है कि शायद तुम सिर्फ दाएं हाथ के हो।
रॉबर्ट हार्वे

मैं इस बात का पालन नहीं करता हूं कि आप इस मामले में कई बाएं जोड़ क्यों नहीं लिख सकते हैं SELECT p.*, o.*, d.* FROM Persons p LEFT JOIN Orders o ON o.CustomerID = p.ID LEFT JOIN SpecialOrders d ON o.Id = d.OrderID:।
ज़ेव स्पिट्ज़

@RobertHarvey मैं हूं, लेकिन मुझे यकीन नहीं है कि हाथ-नेस का इससे क्या लेना-देना है।
Becuzz

@ZevSpitz शायद यह स्पष्ट नहीं था कि मैंने क्या लिखा था, लेकिन विचार यह था कि आप केवल आदेशों से फ़ील्ड चाहते थे यदि एक विशेष ऑर्डर विवरण रिकॉर्ड मौजूद हो, अर्थात। यदि उनमें से जोड़े मौजूद हैं, तो केवल उनसे जुड़ें।
Becuzz

-1

मैं प्रतिकृति / मर्ज उद्देश्यों के लिए उपयोग किए जा रहे राइट जॉइन देख सकता था। मान लीजिए कि मेरे पास दो टेबल A और B. A बाईं तरफ हैं और B दाईं ओर है। मान लीजिए कि मैं इन दोनों तालिका के बीच डेटा को समान बनाने के लिए उन्हें दोहराना चाहता था।

अगर मैं वह सभी डेटा दिखाना चाहता था जो A में था, लेकिन B में नहीं था तो यह एक LEFT जॉइन होगा। अगर मैं B में वह सारा डेटा दिखाना चाहता था जो A में नहीं था तो वह राइट ज्वाइन होगा।

तो, कभी-कभी LEFT और RIGHT तब काम में आती है जब किसी चीज़ को संभावित रूप से रखने के लिए डेटा को मर्ज और प्रतिकृति करते हैं।

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

यहाँ एसक्यूएल जॉन्स की कल्पना करने के लिए एक अच्छा लिंक है।

http://www.codeproject.com/Articles/33052/Visual-Representation-of-SQL-Joins


-1

लेफ्ट जॉइन राइट राइट का विरोध नहीं है, निम्नलिखित मामले की जांच करें जो अलग परिणाम देता है

select * from 
(select 1 as x  where 1=1) a left join 
(select 1 as x  where 1=0) b on a.x=b.x inner join 
(select 1 as x  where 1=1) c on b.x=c.x

select * from 
(select 1 as x where 1=1) c inner join 
(select 1 as x where 1=0) b on c.x=b.x right join 
(select 1 as x where 1=1) a on b.x=a.x

टेबल बी ए सी सी भीतर से जुड़े हुए हैं लेकिन पहले में एक को दूसरों से जोड़ा गया है और दूसरे पर दायां हाथ मिलाया गया है

लेफ्ट ज्वाइन रिटर्न्स नो रोज़ जबकि राईट जॉइन रिट्स रिटर्न


यह और अधिक एक tangential टिप्पणी की तरह है, देखें कैसे जवाब देने के लिए
gnat

-2

पसंद करने का कोई कारण नहीं है RIGHT JOIN, और LEFT JOINबहुत स्पष्ट है:

व्यक्तियों का चयन करें। *, आदेश। व्यक्तियों से कुछ आदेश छोड़ें।

क्योंकि यह आपको तुरंत यह देखने की अनुमति देता है कि किस तालिका को क्वेर किया जा रहा है। जबकि इसके साथ RIGHT JOIN:

सेलेक्ट पर्सन्स। *, ऑर्डर्स। * ऑर्डर्स से जोर्ड्स ओर्ड्स पर ऑर्डर करें। पार्सिड = पर्सन्स ।ID

पहली तालिका के बाद लिखा गया है JOIN

मेरे अनुभव में, मैंने कभी नहीं देखा है RIGHT JOIN


1
यह प्रश्न क्या जोड़ता है? सवाल यह नहीं है कि अंतर क्या है? ; सवाल यह है कि मुझे क्यों इस्तेमाल करना चाहिए RIGHT JOIN?
ज़ेव स्पिट्ज

@ZevSpitz आप जो पसंद करने के लिए कारण पूछते हैं, मैं आपको एक कारण देता हूं। स्वाद के मामले के बाद से कौन सा उपयोग मामला मायने नहीं रखता।
kirie
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.