বাম যোগদানের চেয়ে রাইট জয়েন্টকে প্রাধান্য দেওয়ার কারণ


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
না, একটি বাম জোড় আপনার প্রায়শই সবচেয়ে বেশি প্রয়োজন যা প্রায়শই ক্যাপচার করে এবং তর্ক করা সহজ easier আমার কর্মক্ষেত্রে, ডান সংযোগগুলি রোধ করার জন্য আমাদের কাছে আসলে একটি মানক রয়েছে কারণ তারা প্রয়োজন হয় না এমন কোনও ক্ষেত্রে নেই (যেমন তারা সর্বদা বিপরীত বাম জোড় দ্বারা প্রতিস্থাপিত হতে পারে)।
এমজিডব্লিউ 854

8
আমি নিকটতম ভোটগুলি পুনরায় সেট করেছি - এই প্রশ্নটি এখানে বিষয়বস্তুতে রয়েছে, যেহেতু যোগদানের মধ্যে পার্থক্য বোঝার ফলে সফ্টওয়্যার ডিজাইন প্রভাবিত হয় (ডাটাবেস কোয়েস্ট করতে পারে এমন অ্যালগোরিদম যেমন সফ্টওয়্যার ডিজাইনের অংশ) ডাটাবেস ডিজাইন) এটি ডেটাবেস প্রশাসকদের বিষয়বস্তুতেও থাকতে পারে এবং সেখানে একটি সদৃশও থাকতে পারে।
থমাস ওভেনস

1
আমি নিশ্চিত নই আপনি RIGHT JOINপ্রস্তাবিত বা আরও সাধারণ হিসাবে পরামর্শ দিচ্ছেন কিনা। যদি এটি আপনার ভিত্তি হয় তবে এটি ভুল। আমি এমন কোনও সময় ভাবতে পারি না যা আমি কখনও কোড বা উদাহরণে ব্যবহার করে সঠিকভাবে যোগদান করতে দেখেছি। এটা JOINবা LEFT OUTER JOIN। বিরল ক্ষেত্রে আপনি একটি দেখতে পারেন FULL OUTER JOIN
জিমি জেমস

উত্তর:


12

আপনি কোন প্রয়োজনটি পূরণ করার চেষ্টা করছেন তার উপর এটি নির্ভর করে।

এটা বলা একই না: "সব ব্যক্তি ও তাদের সংশ্লিষ্ট আদেশ লাগাও" যে "আমি তাদের সংশ্লিষ্ট ব্যক্তিদের সঙ্গে সমস্ত আদেশ চাই" , বিশেষ করে যদি আপনি ব্যবহার করতে যাচ্ছি is nullকোন সংশ্লিষ্ট ম্যাচ দিয়ে সারি আনতে। এটিকেই আমি "প্রভাবশালী টেবিল" বলি, এটি যে টেবিলটি আমি জোয়ারের অপর প্রান্তে সঠিক সংযোগ স্থাপন না করেই সারিগুলি পেতে চাই want

এই চিত্রগুলি দেখুন এবং আপনি লক্ষ্য করবেন যে সেগুলি এক নয়:

এখানে চিত্র বর্ণনা লিখুন

চিত্র উত্স এই দুর্দান্ত নিবন্ধ

তবে আপনি ঠিক বলেছেন যে উভয় প্রয়োজনীয়তা কেবলমাত্র যোগদানের টেবিলের ক্রমটিকে উল্টিয়ে দেওয়াতে যোগদানের মাধ্যমে পূরণ করা যেতে পারে।

তবে আমি অনুমান করি যে পাশ্চাত্য লোকেদের বাম থেকে ডান লেখার পক্ষে অভ্যস্ত হওয়া ডান সংযুক্তির উপর বাম সংযোগগুলি ব্যবহার করা আরও স্বাভাবিকভাবেই আসে , যেহেতু আমরা দেখতে পাই যে আমরা দেখতে চাইছি একই দিকে বা selectএড কলামের মতো একই ক্রমে যুক্ত হতে চাই ।

সুতরাং ডান যোগদানকে পছন্দ করার সম্ভাব্য কারণ হ'ল কারণ আপনার সংস্কৃতিতে আপনি ডান থেকে বামে লিখেন (যেমন আরবি বা হিব্রু রচনা পদ্ধতিতে) এবং আপনি সেভাবেই ভাবতে চান, সম্ভবত আপনার মস্তিষ্কের পাঠ্য তথ্য ডান থেকে বামে প্রবাহিত হয় ।

কিছু ভাষাতত্ত্ববিদ মনে করেন আপনার ভাষা আপনার চিন্তাভাবনাকে প্রভাবিত করে: https://www.edge.org/conversation/lera_boroditsky-how-does-our-language-shape-the-way-we-think


1
আমি এই লাইন ধরে ভাবতে শুরু করেছি, তবে আমি এটি সঠিক বলে মনে করি না। আমি হিব্রুতে এসকিউএল লেখার কল্পনা শুরু করেছি (যা আমি আসলে কখনও করি নি)। ঠিক আছে: ডান থেকে ন্যায়সঙ্গত, ডান থেকে বাম, উপরে-নীচে। আপনি এখনও সারণি একটি প্রথমে টেবিল বি উল্লেখ করবেন একটি ডান যোগদানের পরে, আপনি প্রথমে উল্লিখিত সারণীর বেশিরভাগ বা সমস্ত বাদ দেবেন (বিশেষ করে নাল ক্ষেত্রে)। আমি মনে করি যে মানব মন প্রথমে প্রাথমিক এবং সবচেয়ে গুরুত্বপূর্ণটির সাথে মিলিত হতে থাকে । দিকনির্দেশনা নির্বিশেষে এটি ঘটে। আপনি তাদের "প্রথম যোগদান" এবং "দ্বিতীয় জয়েন" বলতে পারেন এবং এই পক্ষপাতিত্ব এখনও ঘটবে।
মাইক

আপনি নীচে প্রদর্শিত চিত্রটির একটি লিঙ্ক আমি অন্তর্ভুক্ত করেছি।
জন রেইনর

@ মাইক আমি আরবি বা হিব্রুতে লোকেরা এসকিউএল লেখার পরামর্শ দিচ্ছি না। কেবলমাত্র আপনার মাতৃভাষার অভিমুখীকরণ আপনাকে ডান-যোগ দানের পক্ষে পছন্দ করার কারণ হতে পারে। তবে তা কেবল একটি সম্ভাবনা। আমি বামে আরও প্রাকৃতিকভাবে যোগ দেয়।
তুলিনস কর্ডোভা

এখন আমি চিত্রটির স্রষ্টাকে যথাযথ কৃতিত্ব দিয়েছি। আমার এইচডি তে বছরের পর বছর ধরে ছিলাম এবং কোথা থেকে এসেছে তা আমার মনে নেই,
তুলিনস কর্ডোভা

আমি হিব্রুতে সাবলীল এবং এখনও আমি LEFT JOINআরও প্রাকৃতিক দেখতে পাই ।
জেভ স্পিটজ

3

এমন কোনও কিছুই নেই (যা আমি জানি) যা ডান জোড় দিয়ে করা যায় যা বাম জোড় দিয়ে করা যায় না। তবে কখনও কখনও বাম জোড়গুলির সাথে সিনট্যাক্সটি খারাপ হয়। ধরা যাক আপনার নিম্নলিখিত সারণী রয়েছে:

Persons
ID | Name

Orders
ID | CustomerId | other unimportant stuff

SpecialOrderDetails
ID | OrderId | other stuff

আসুন আমরা আপনার ডাটাবেসে সমস্ত লোকের একটি তালিকা এবং বিশেষ আদেশের বিশদ সহ তাদের যে কোনও আদেশ পেতে হবে তা জানতে হবে (আমরা বলব যে সমস্ত আদেশের বিশেষ অর্ডার বিশদ নেই)। সুতরাং আপনি সাধারণত অর্ডারগুলিতে লোকের কাছ থেকে একটি বাম সংযুক্তি করতেন। তবে তারপরে আপনাকে বিশেষ ক্রমের বিশদে বিশদে যোগ দিতে হবে। আপনি যদি সেখানে কোনও অভ্যন্তরীণ যোগদান ব্যবহার করেন, তবে এটি কার্যকরভাবে বামগুলিকে লোকের কাছ থেকে অভ্যন্তরীণ যোগদানের আদেশ দেয়। আইই: আপনি যা করতে চান এটি কিন্তু কাজ করে না (এটি যার যার বিশেষ অর্ডার নেই তাকে বাদ দেবে):

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

এই মুহুর্তে, এটি সবচেয়ে স্পষ্ট কী এবং বেশিরভাগ লোকেরা কী বুঝতে পারে তার একটি পছন্দ (আপনি কি জানতেন না যে কীভাবে সিনট্যাক্স গুগল করবেন যদি আপনি না জানতেন তবে এটি নেস্টেড জয়েন বলা হত?)।

সংক্ষেপে, আপনার কঠোরভাবে সঠিক যোগদানের দরকার নেই তবে এগুলি পড়া সহজতর হতে পারে।


আমি মনে করি আপনি ঠিক ডান হাতের।
রবার্ট হার্ভে

আমি অনুসরণ না কেন আপনি একাধিক বাম এই ক্ষেত্রে যোগদান করে লিখতে পারি না: 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
জেভ স্পিটজ

পছন্দ করেছেন
বেকুজ

@ জেভস্পিট্জ সম্ভবত আমি যা লিখেছি তা থেকে এটি পরিষ্কার ছিল না, তবে ধারণাটি ছিল আপনি কেবলমাত্র আদেশগুলি থেকে ক্ষেত্রগুলি চান কেবল যদি একটি বিশেষ আদেশের বিশদ বিবরণ রেকর্ড উপস্থিত থাকে, অর্থাত্। বাম তাদের সাথে যোগ দিন কেবল যদি তাদের জুড়িটি বিদ্যমান থাকে।
বেকুজ

-1

আমি দেখতে পেলাম একটি সঠিক যোগদানের প্রতিরূপকরণ / একীকরণের উদ্দেশ্যে ব্যবহৃত হচ্ছে। ধরা যাক আমার দুটি টেবিল A ​​এবং B রয়েছে A এ বাম দিকে আছে এবং বি ডানদিকে রয়েছে। ধরা যাক আমি এই দুটি টেবিলের সমতুল্য করার জন্য ডেটাগুলি প্রতিলিপি করতে চেয়েছিলাম।

আমি যদি A তে ছিল তবে বি তে থাকা সমস্ত ডেটা দেখাতে চাইতাম তবে এটি একটি বাম যোগদান হতে পারে। আমি যদি বি তে থাকা সমস্ত ডেটা দেখাতে চাইতাম যা এটিতে ছিল না তবে এটি যুক্ত হবে।

সুতরাং, জিনিসগুলিকে সম্ভাব্য রাখার জন্য ডেটা মার্জ করে এবং প্রতিলিপি দেওয়ার সময় কখনও কখনও বাম এবং ডানদিকে আসে।

এগুলি ছাড়াও, আমি কোনও রাইট সংযুক্তি ব্যবহার করার অন্য কোনও কারণ দেখতে পাচ্ছি না কারণ সমস্ত ডানদিকে যোগ দেওয়া থেকে বাম অংশে রূপান্তর করা যায় বা বিপরীতভাবে সমস্ত বামে যোগদান করে কীভাবে সারণিগুলি অর্ডার করা হয় বা ভিজ্যুয়ালাইজ করা হয় তার উপর নির্ভর করে ডানদিকে যোগদান করতে পারে। সুতরাং, এটি অন্যান্য ক্ষেত্রে অগ্রাধিকারের বিষয় হবে।

এসকিউএল জয়েনদের কল্পনা করার জন্য এখানে একটি দুর্দান্ত লিঙ্ক।

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

টেবিল বি এনসি সি সর্বত্র অভ্যন্তরীণভাবে যুক্ত হয় তবে প্রথমটিতে একটি অন্যের সাথে যুক্ত থাকে এবং দ্বিতীয়টিতে একটি ডানদিকে যোগ হয়

বাম যোগদান কোনও সারি দেয় না যখন ডান জোড় একটি সারিতে ফিরে আসে


এই আরো একটি স্পর্শিনী মন্তব্য দেখে মনে পড়লো, দেখুন উত্তর কিভাবে
মশা

-2

পছন্দ করার কোনও কারণ নেই RIGHT JOINএবং LEFT JOINএটি আরও পরিষ্কার:

ব্যক্তি নির্বাচন করুন। *, অর্ডার। * ব্যক্তিগণ থেকে বামে যোগ দিন অর্ডারগুলিতে আই.ডি = অর্ডার.পারসনআইডি

এটি আপনাকে তাত্ক্ষণিকভাবে দেখতে দেয় যে কোন টেবিলটি জিজ্ঞাসা করা হচ্ছে। যেখানে সাথে RIGHT JOIN:

আদেশ নির্বাচন করুন। *, অর্ডার। * অর্ডার থেকে অর্ডারস ডান যুক্ত ব্যক্তিদের অর্ডার করুন। পার্সোনাইড = পার্সোনস.আইডি

প্রথম টেবিলটি পরে লেখা আছে JOIN

আমার অভিজ্ঞতায় আমি কখনও দেখিনি RIGHT JOIN


1
এটি প্রশ্নে কী যুক্ত করে? প্রশ্ন না পার্থক্য কি? ; প্রশ্নটি কেন আমার ব্যবহার করা উচিত RIGHT JOIN?
জেভ স্পিটজ

@ জেভস্পিজ আপনি কোনটি পছন্দ করার কারণ জিজ্ঞাসা করছেন, আমি আপনাকে একটি কারণ দিই এটি স্বাদের বিষয়টি যেহেতু ব্যবহারের ক্ষেত্রে গুরুত্বপূর্ণ নয়।
কিরি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.