دستورات پیوند و Join در SQL

SQL JOIN یکی از دستورهای مهم برای کار با پایگاه داده‌های رابطه‌ای است. با استفاده از آن می‌توان اطلاعات مرتبطی را که در جدول‌های جداگانه ذخیره شده‌اند، بر اساس یک شرط مشترک کنار هم قرار داد. برای نمونه، مشخصات مشتری ممکن است در یک جدول و سفارش‌های او در جدولی دیگر نگهداری شود؛ پیوند این دو جدول کمک می‌کند سفارش‌ها را همراه با اطلاعات مشتری مشاهده کنید.

جدا نگه‌داشتن داده‌ها در جدول‌های مرتبط، از تکرار غیرضروری اطلاعات جلوگیری می‌کند و نگهداری پایگاه داده را ساده‌تر می‌سازد. با این حال، هنگام گزارش‌گیری یا نمایش داده‌ها معمولاً لازم است بخش‌هایی از این اطلاعات دوباره در یک خروجی ترکیب شوند. اینجاست که انتخاب نوع مناسب JOIN اهمیت پیدا می‌کند: هر نوع پیوند، شیوه متفاوتی برای برخورد با ردیف‌های بدون تطابق دارد.

مجموعه دستورهای Join در SQL برای پیوند جدول‌ها در پایگاه داده به کار می‌رود. معمولاً رابطه میان جدول‌ها از طریق کلید اصلی و کلید خارجی برقرار است؛ اما شرط JOIN می‌تواند بر اساس هر ستون یا ترکیبی از ستون‌ها تعریف شود، به شرط آنکه منطق داده‌ها چنین پیوندی را توجیه کند.

دستور INNER JOIN ردیف‌هایی را در خروجی قرار می‌دهد که شرط پیوند در هر دو جدول برای آن‌ها برقرار باشد. اگر یک مشتری هیچ سفارش ثبت‌شده‌ای نداشته باشد، اطلاعات او در نتیجه این پیوند دیده نمی‌شود؛ همچنین سفارش‌هایی که شناسه مشتری معتبر یا منطبق ندارند نیز در خروجی قرار نمی‌گیرند.

برای مثال، فرض کنید جدول Customers شامل شناسه و نام مشتریان باشد و جدول Orders شناسه مشتری و مبلغ سفارش را نگهداری کند. اگر گزارش فقط باید مشتریانی را نشان دهد که دست‌کم یک سفارش دارند، INNER JOIN انتخاب مناسبی است. به این ترتیب، خروجی شامل اطلاعات مشتری و سفارش‌هایی خواهد بود که شناسه مشتری آن‌ها در هر دو جدول پیدا می‌شود.

SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
INNER JOIN Orders
  ON Customers.CustomerID = Orders.CustomerID;

در این پرس‌وجو، شرط پس از ON مشخص می‌کند کدام ردیف‌ها با هم مرتبط هستند. اگر یک مشتری چند سفارش داشته باشد، ممکن است نام همان مشتری در چند ردیف خروجی تکرار شود؛ این رفتار طبیعی است، چون هر ردیف خروجی نماینده یک جفت منطبق از اطلاعات جدول‌هاست، نه لزوماً یک مشتری یکتا.

مطالعه بیشتر درباره دستور INNER JOIN کمک می‌کند با جزئیات شرط‌های پیوند و نمونه‌های کاربردی آن آشنا شوید. هنگام استفاده، بهتر است نام جدول و ستون را صریح بنویسید تا در پرس‌وجوهای چندجدولی، تشخیص منبع هر ستون دشوار نشود.

دستور LEFT JOIN همه ردیف‌های جدول سمت چپ را در نتیجه نگه می‌دارد؛ حتی اگر برای بعضی از آن‌ها ردیف متناظری در جدول سمت راست وجود نداشته باشد. در چنین مواردی، ستون‌های مربوط به جدول راست با مقدار NULL نمایش داده می‌شوند.

این نوع پیوند زمانی سودمند است که بخواهید اطلاعات پایه را کامل ببینید و در کنار آن، داده‌های مرتبط را نیز در صورت وجود نمایش دهید. مثلاً اگر هدف تهیه فهرستی از همه مشتریان، همراه با سفارش‌هایشان باشد، LEFT JOIN مشتریان بدون سفارش را حذف نمی‌کند. این تفاوت، آن را برای گزارش‌هایی که نباید اعضای جدول اصلی را از دست بدهند، مناسب می‌کند.

SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
LEFT JOIN Orders
  ON Customers.CustomerID = Orders.CustomerID;

در این مثال، Customers جدول چپ است؛ بنابراین همه مشتریان در خروجی باقی می‌مانند. اگر مشتری سفارشی نداشته باشد، OrderID مقدار NULL خواهد داشت. برای پیدا کردن مشتریان بدون سفارش می‌توان پس از پیوند، شرطی مانند WHERE Orders.OrderID IS NULL را بررسی کرد.

به جزئیات دستور LEFT JOIN توجه کنید: جای جدول‌ها در این عملگر اهمیت دارد. جابه‌جا کردن جدول چپ و راست ممکن است نتیجه را تغییر دهد، چون LEFT JOIN همیشه ردیف‌های جدول نوشته‌شده در سمت چپ عبارت را حفظ می‌کند.

دستور RIGHT JOIN رفتاری مشابه LEFT JOIN دارد، با این تفاوت که همه ردیف‌های جدول سمت راست را نگه می‌دارد. اگر برای یکی از ردیف‌های جدول راست، مورد متناظری در جدول چپ پیدا نشود، ستون‌های جدول چپ در آن ردیف با NULL پر می‌شوند.

برای نمونه، اگر جدول سفارش‌ها در سمت راست و جدول مشتریان در سمت چپ قرار گیرد، RIGHT JOIN می‌تواند همه سفارش‌ها را نگه دارد؛ حتی اگر رکورد متناظر مشتری برای بعضی از سفارش‌ها در دسترس نباشد. البته چنین وضعیتی ممکن است نشانه داده ناقص یا ناسازگاری در پایگاه داده باشد و بررسی آن به کیفیت رابطه‌ها بستگی دارد.

SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
RIGHT JOIN Orders
  ON Customers.CustomerID = Orders.CustomerID;

در بسیاری از پروژه‌ها می‌توان با جابه‌جایی ترتیب جدول‌ها و استفاده از LEFT JOIN به نتیجه مشابه رسید. برای مثال، اگر هدف حفظ همه ردیف‌های Orders باشد، می‌توان Orders را در سمت چپ عبارت قرار داد و Customers را با LEFT JOIN به آن پیوند زد. گاهی این شکل نوشتن برای خواننده روشن‌تر است، چون جدول اصلی گزارش در ابتدای عبارت دیده می‌شود.

برای بررسی نمونه‌ها و رفتار دقیق این عملگر، مقاله دستور RIGHT JOIN را ببینید. هنگام بازبینی یک پرس‌وجو، همیشه مشخص کنید کدام جدول باید بدون حذف در خروجی باقی بماند؛ همین تصمیم معمولاً به انتخاب بین LEFT JOIN و RIGHT JOIN کمک می‌کند.

دستور FULL JOIN ردیف‌های منطبق را کنار هم قرار می‌دهد و ردیف‌های بدون تطابق هر دو جدول را نیز حفظ می‌کند. اگر یک ردیف فقط در جدول اول وجود داشته باشد، ستون‌های جدول دوم برای آن ردیف NULL می‌شوند؛ اگر فقط در جدول دوم باشد، وضعیت برعکس خواهد بود.

این عملگر برای مقایسه دو مجموعه داده یا شناسایی مواردی که در یکی از دو منبع وجود دارند کاربرد دارد. فرض کنید دو فهرست مشتری از دو سامانه مختلف دارید و می‌خواهید هم رکوردهای مشترک و هم رکوردهایی را که فقط در یکی از فهرست‌ها دیده می‌شوند بررسی کنید. FULL JOIN می‌تواند نقطه شروع چنین گزارشی باشد.

SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
FULL JOIN Orders
  ON Customers.CustomerID = Orders.CustomerID;

پشتیبانی از FULL JOIN در همه سامانه‌های پایگاه داده یکسان نیست؛ بنابراین پیش از اجرای پرس‌وجو باید مستندات موتور پایگاه داده خود را بررسی کنید. اگر این عملگر در دسترس نباشد، گاهی می‌توان نتیجه‌ای مشابه را با ترکیب پرس‌وجوهای مناسب ساخت، اما روش جایگزین باید با توجه به سامانه و منطق داده طراحی و آزمایش شود.

اطلاعات تکمیلی درباره دستور FULL JOIN به شما کمک می‌کند خروجی آن را از پیوندهای یک‌طرفه تشخیص دهید. هنگام تحلیل نتیجه، به NULLها و علت ایجاد آن‌ها توجه کنید؛ NULL در اینجا می‌تواند به معنی نبود ردیف متناظر باشد، نه الزاماً وجود یک مقدار ذخیره‌شده خالی در داده اصلی.

در بیشتر سامانه‌های SQL، نوشتن JOIN بدون مشخص‌کردن نوع آن، معادل INNER JOIN است. بنابراین نتیجه منطقی این دو شکل، با شرط پیوند یکسان، معمولاً تفاوتی ندارد. واژه JOIN در این حالت شکل کوتاه‌تری برای نوشتن INNER JOIN محسوب می‌شود.

گاهی گفته می‌شود یکی از این دو شکل همیشه سریع‌تر است؛ چنین ادعایی را نمی‌توان به‌طور کلی درست دانست. بهینه‌ساز پایگاه داده معمولاً عبارت‌های هم‌معنا را به شکل اجرایی مشابه تبدیل می‌کند، اما کارایی واقعی به موتور پایگاه داده، حجم داده، شاخص‌ها، آمار جدول‌ها و ساختار پرس‌وجو بستگی دارد. اگر سرعت مهم است، باید اجرای پرس‌وجو را در محیط واقعی و با ابزارهای تحلیل همان سامانه بررسی کرد.

از نظر خوانایی، استفاده صریح از INNER JOIN می‌تواند در پرس‌وجوهای پیچیده مفید باشد؛ زیرا نوع رابطه را روشن نشان می‌دهد و مقایسه آن با LEFT JOIN یا سایر انواع را آسان‌تر می‌کند. در پرس‌وجوهای ساده، JOIN نیز قابل استفاده است، اما بهتر است در یک پروژه از شیوه نگارش یکدست پیروی کنید تا نگهداری کد برای اعضای تیم دشوار نشود.

در نتیجه، انتخاب بین واژه JOIN و INNER JOIN بیشتر به وضوح و قرارداد نگارش تیم مربوط است، نه یک قانون ثابت درباره کارایی. برای بهبود عملکرد، طرح اجرای پرس‌وجو را بررسی کنید، ستون‌های شرط پیوند را بشناسید و از ایجاد پیوندهای غیرضروری پرهیز کنید.

پیش از نوشتن پرس‌وجو، سؤال اصلی گزارش را به زبان ساده بیان کنید. آیا فقط رکوردهایی را می‌خواهید که در دو جدول رابطه دارند؟ INNER JOIN معمولاً با این نیاز سازگار است. آیا باید همه ردیف‌های یک جدول مشخص، حتی بدون داده مرتبط، باقی بمانند؟ در این صورت، آن جدول را در سمت چپ LEFT JOIN قرار دهید یا با RIGHT JOIN ردیف‌های جدول راست را حفظ کنید.

برای مثال، اگر فهرست همه محصولات را همراه با دسته‌بندی آن‌ها می‌خواهید، باید تعیین کنید محصول بدون دسته‌بندی نیز در گزارش دیده شود یا نه. اگر پاسخ مثبت است، جدولی که باید کامل بماند را در سمت حفظ‌شونده پیوند قرار دهید. همین تصمیم کوچک از حذف ناخواسته ردیف‌ها جلوگیری می‌کند.

شرط ON باید ستون‌هایی را مقایسه کند که واقعاً رابطه موردنظر را نشان می‌دهند. پیوند دو ستون نامرتبط می‌تواند تعداد ردیف‌های زیادی تولید کند یا نتیجه‌ای گمراه‌کننده بسازد. اگر نام ستون‌ها در دو جدول یکسان است، همچنان نوشتن نام جدول در کنار نام ستون به خوانایی و جلوگیری از ابهام کمک می‌کند.

همچنین نوع داده و کیفیت مقدارهای پیوند را بررسی کنید. فاصله‌های اضافی، قالب‌های متفاوت شناسه یا مقدارهای ناقص ممکن است باعث شوند ردیف‌هایی که از نظر انسانی مرتبط به نظر می‌رسند، در شرط SQL با هم تطابق نداشته باشند. بهتر است علت ناسازگاری در داده یا مدل پایگاه داده مشخص شود، نه اینکه با یک شرط مبهم پنهان بماند.

پس از اجرای پرس‌وجو، چند ردیف نمونه را با داده‌های جدول اصلی تطبیق دهید. شمارش ردیف‌ها به‌تنهایی کافی نیست، چون یک رابطه یک‌به‌چند ممکن است باعث شود اطلاعات یک رکورد در چند ردیف تکرار شود. این تکرار الزاماً خطا نیست؛ باید دید آیا با هدف گزارش و سطح جزئیات خروجی هماهنگ است یا خیر.

اگر نتیجه بیش از انتظار ردیف دارد، شرط ON و تعداد تطابق‌ها را بررسی کنید. اگر ردیف‌هایی حذف شده‌اند، نوع JOIN و فیلترهای WHERE را بازبینی کنید. به‌خصوص در پرس‌وجوهای دارای LEFT JOIN، قرار دادن شرطی برای ستون جدول راست در WHERE ممکن است برخی ردیف‌های بدون تطابق را حذف کند و نتیجه را از رفتار مورد انتظار دور سازد.

در پرس‌وجوهای چندجدولی، استفاده از نام کامل ستون‌ها احتمال ابهام را کم می‌کند. اگر نام جدول طولانی است، می‌توانید از نام مستعار استفاده کنید؛ به شرط آنکه نام مستعار گویا باشد و در سراسر پرس‌وجو یکدست بماند. این روش به‌خصوص هنگامی مفید است که چند جدول ستون‌هایی با نام یکسان، مانند ID یا Name، داشته باشند.

همچنین بهتر است هر JOIN را با شرط ON مرتبط و قابل بررسی بنویسید و از پیوندهای بدون شرط آگاهانه استفاده کنید. پیوند بدون شرط ممکن است ترکیب‌های بسیار زیادی از ردیف‌ها بسازد و حجم نتیجه را به‌شدت افزایش دهد. اگر چنین رفتاری هدف شما نیست، شرط پیوند را پیش از اجرا با دقت بازبینی کنید.

برای آموزش یا مستندسازی پایگاه داده، مثال را با نام جدول‌ها و ستون‌هایی انتخاب کنید که نقش آن‌ها روشن باشد. مثلاً رابطه مشتری و سفارش برای توضیح پیوند یک‌به‌چند قابل فهم است. پس از آن، می‌توان همان منطق را به جدول‌های واقعی پروژه تعمیم داد و تفاوت میان ردیف منطبق و بدون تطابق را بررسی کرد.

در صورت نیاز به یادگیری عمیق‌تر، مقاله‌های جداگانه مربوط به INNER JOIN در SQL، LEFT JOIN در SQL، RIGHT JOIN در SQL و FULL JOIN در SQL را مطالعه کنید. این مطالب هر نوع پیوند را با جزئیات بیشتر و نمونه‌های مرتبط توضیح می‌دهند.

انتخاب SQL JOIN مناسب به این بستگی دارد که کدام ردیف‌ها باید در خروجی باقی بمانند. INNER JOIN برای داده‌های دارای تطابق در هر دو جدول مناسب است؛ LEFT JOIN همه ردیف‌های جدول چپ را حفظ می‌کند؛ RIGHT JOIN همین کار را برای جدول راست انجام می‌دهد؛ و FULL JOIN ردیف‌های هر دو جدول را، چه دارای تطابق باشند و چه نباشند، نمایش می‌دهد.

به جای حفظ کردن نام‌ها به‌تنهایی، رفتار هر نوع پیوند را با یک مثال کوچک آزمایش کنید و نتیجه را با نیاز گزارش خود بسنجید. توجه به شرط ON، جایگاه جدول‌ها، مقدارهای NULL و احتمال تکرار ردیف‌ها باعث می‌شود خروجی قابل اعتمادتر و کد خواناتر باشد. برای تکمیل مهارت‌های فنی خود می‌توانید درباره طراحی سایت و توسعه بخش‌های مرتبط با پایگاه داده نیز اطلاعات بیشتری کسب کنید.