LEFT JOIN في SQLite: شرح كامل مع أمثلة عملية

LEFT JOIN يحتفظ بكل شيء من الجدول الأيسر

عبارة INNER JOIN تُرجع فقط الصفوف التي يوجد لها تطابق في الطرفين. هذا غالبًا ما تحتاجه فعلًا، لكن ليس دائمًا. أحيانًا يكون "عدم وجود تطابق" هو بحدّ ذاته الإجابة التي تبحث عنها: المستخدمون الذين لم يُجروا أي طلب، المنتجات التي لم تُبَع قط، المقالات التي لا تحوي أي تعليق. في مثل هذه الحالات تحتاج إلى LEFT JOIN.

تقوم LEFT JOIN في SQLite بإرجاع كل صف من الجدول الأيسر. فإن وُجد صف مطابق في الجدول الأيمن، حصلت على قيم الأعمدة المطابقة. وإن لم يوجد، يبقى الصف الأيسر ظاهرًا، وتأتي أعمدة الجدول الأيمن بقيمة NULL.

CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    name TEXT
);

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    user_id INTEGER REFERENCES users(id),
    total REAL
);

INSERT INTO users (id, name) VALUES (1, 'Ada'), (2, 'Boris'), (3, 'Cleo');
INSERT INTO orders (user_id, total) VALUES (1, 49.99), (1, 12.50), (2, 99.00);

SELECT u.name, o.total
FROM users AS u
LEFT JOIN orders AS o ON o.user_id = u.id;

كليو ليس لديها أي طلبات، ومع ذلك تظهر في النتيجة — لكن مع NULL في عمود total. لو استبدلت LEFT JOIN بـ INNER JOIN، فستختفي كليو تمامًا.

الفكرة الذهنية وراء LEFT JOIN في SQLite

اقرأ الاستعلام من الأعلى إلى الأسفل، وتخيّل أن الجدول الأول (الأيسر) هو جدول المرجع أو "المرساة". كل صف في users سيظهر في النتيجة، مهما كانت الظروف. ثم يأتي دور LEFT JOIN ليسأل عن كل مستخدم: "هل يوجد صف مطابق في جدول orders؟"

• وُجد تطابق ← يتم لصق أعمدة الصف المطابق بصف المستخدم.
• تطابقات متعددة ← يُنتج صفًا واحدًا لكل تطابق (لدى آدا طلبان، فتظهر مرتين).
• لا يوجد تطابق ← يُنتج صفًا واحدًا، وتكون كل أعمدة الجدول الأيمن فيه NULL.

هذه الحالة الأخيرة هي السبب الرئيسي لوجود LEFT JOIN أصلًا. وقيمة NULL هنا لا تعني "لا نعرف"، بل تعني "لا يوجد شيء في الجدول الأيمن لإلصاقه".

أما LEFT OUTER JOIN فهو نفس العملية تمامًا. كلمة OUTER اختيارية في SQLite، ومعظم المطورين يحذفونها.

كيفية إيجاد الصفوف التي لا تملك تطابقًا

الاستخدام الكلاسيكي لـ LEFT JOIN هو إيجاد الصفوف الموجودة في الجدول الأيسر والتي ليس لها أي تطابق في الجدول الأيمن. الحيلة هنا هي أن تضع شرط التصفية على عمود من الجدول الأيمن يكون NOT NULL في البيانات الفعلية — عادةً ما يكون المفتاح الأساسي — ثم تتحقق من قيمة NULL بعد عملية الربط:

CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT);
CREATE TABLE orders (id INTEGER PRIMARY KEY, user_id INTEGER, total REAL);

INSERT INTO users VALUES (1, 'Ada'), (2, 'Boris'), (3, 'Cleo');
INSERT INTO orders VALUES (1, 1, 49.99), (2, 2, 99.00);

SELECT u.name
FROM users AS u
LEFT JOIN orders AS o ON o.user_id = u.id
WHERE o.id IS NULL;

ستظهر لك «كليو» فقط. عملية الـ JOIN تربط بيانات الطلبات حيث تكون موجودة، ثم يأتي شرط WHERE o.id IS NULL ليُبقي فقط الصفوف التي فشل فيها الربط. يُطلق على هذا النمط أحيانًا اسم "anti-join" أو الربط العكسي.

الفرق بين ON و WHERE: الفخّ الخفي

هذا أكثر خطأ شائع يقع فيه المبرمجون عند استخدام LEFT JOIN، ويستحق وقفة متأنية. الشروط يمكن وضعها إما داخل جملة ON أو داخل جملة WHERE، لكن سلوكها مع الـ outer joins يختلف اختلافًا جوهريًا.

• جملة ON تُنفَّذ أثناء عملية الربط نفسها، وشروطها تُحدّد أيّ صفوف من الجدول الثاني تُعتبر مطابقة.
• جملة WHERE تُنفَّذ بعد أن ينتهي الربط من إنتاج صفوفه، فهي تُصفّي النتيجة النهائية المدمجة.

والآن لاحظ ما يحدث عندما تضع شرطًا على الجدول الثاني داخل WHERE:

CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT);
CREATE TABLE orders (id INTEGER PRIMARY KEY, user_id INTEGER, status TEXT);

INSERT INTO users VALUES (1, 'Ada'), (2, 'Boris'), (3, 'Cleo');
INSERT INTO orders VALUES (1, 1, 'shipped'), (2, 2, 'pending');

-- خطأ: يحوّل LEFT JOIN بصمت إلى INNER JOIN
SELECT u.name, o.status
FROM users AS u
LEFT JOIN orders AS o ON o.user_id = u.id
WHERE o.status = 'shipped';

كليو ليس لديها أي طلب، لذلك تكون قيمة o.status بالنسبة لصفّها هي NULL، والمقارنة NULL = 'shipped' لا تُعتبر صحيحة، فيتم استبعادها من النتائج. وبوريس حالته 'pending' فيُستبعد هو الآخر. وهكذا يكون LEFT JOIN قد تحوّل ضمنيًا إلى INNER JOIN دون أن تشعر.

الحل: ننقل الشرط إلى داخل ON، حتى يعمل على تصفية التطابقات لا الصفوف الناتجة:

CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT);
CREATE TABLE orders (id INTEGER PRIMARY KEY, user_id INTEGER, status TEXT);

INSERT INTO users VALUES (1, 'Ada'), (2, 'Boris'), (3, 'Cleo');
INSERT INTO orders VALUES (1, 1, 'shipped'), (2, 2, 'pending');

SELECT u.name, o.status
FROM users AS u
LEFT JOIN orders AS o ON o.user_id = u.id AND o.status = 'shipped';

الآن يظهر كل المستخدمين في النتيجة. آدا يظهر معها طلبها المُرسَل، وبوريس تظهر معه قيمة NULL (لأن طلبه المعلّق لم يحقق شرط المطابقة)، وكليو أيضًا تظهر معها NULL (لأنها لا تملك أي طلبات أصلًا). وهذه هي الإجابة الصحيحة حين يكون السؤال: "اعرض لي كل المستخدمين، مع طلباتهم المُرسَلة إن وُجدت".

قاعدة عامة تستحق الحفظ: الشروط المتعلقة بالجدول الأساسي (يسار العملية) يمكن وضعها في WHERE، أما الشروط المتعلقة بالجدول الثانوي فمكانها الطبيعي داخل ON — إلا إذا كنت تقصد تحديدًا اصطياد الصفوف غير المتطابقة عبر IS NULL.

العدّ باستخدام LEFT JOIN في SQLite

من أكثر المهام شيوعًا: عدّ الصفوف المرتبطة بكل سجل أب، مع تضمين الآباء الذين ليس لديهم أي صفوف مرتبطة. لو استخدمت INNER JOIN فستختفي الأصفار من النتيجة. لكن مع LEFT JOIN ودالة COUNT على عمود من الجدول الثانوي تحصل على الإجابة الصحيحة:

CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT);
CREATE TABLE orders (id INTEGER PRIMARY KEY, user_id INTEGER, total REAL);

INSERT INTO users VALUES (1, 'Ada'), (2, 'Boris'), (3, 'Cleo');
INSERT INTO orders VALUES (1, 1, 49.99), (2, 1, 12.50), (3, 2, 99.00);

SELECT u.name, COUNT(o.id) AS order_count, COALESCE(SUM(o.total), 0) AS revenue
FROM users AS u
LEFT JOIN orders AS o ON o.user_id = u.id
GROUP BY u.id, u.name
ORDER BY u.name;

شيئان يستحقان الانتباه:

• COUNT(o.id) يعدّ الصفوف غير الفارغة من الجهة الأخرى للربط. لذلك تحصل Cleo على 0 وليس 1، لأن COUNT يتجاهل قيم NULL. أما لو كتبت COUNT(*) فستحصل Cleo على 1 (الصف موجود فعلاً، لكن قيمه NULL). في الغالب، COUNT(right.id) هو ما تريده فعلاً.
• COALESCE(SUM(o.total), 0) يحوّل ناتج جمع Cleo من NULL إلى 0. بدونه ستظهر إيراداتها كـ NULL، وهو أمر صحيح تقنياً لكنه قبيح المنظر عند العرض.

ربط جداول متعددة في SQLite

يمكن تسلسل عدة LEFT JOIN خلف بعضها. كل عملية ربط تأخذ النتيجة المتراكمة وتضم إليها جدولاً جديداً. وبمجرد أن تجعل عموداً قابلاً لاحتواء NULL عبر LEFT JOIN، استمر باستخدام LEFT JOIN مع أي جدول يتفرع منه — وإلا فإن أول INNER JOIN تالٍ سيُسقط بصمت الصفوف التي كنت تريد الاحتفاظ بها.

CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT);
CREATE TABLE orders (id INTEGER PRIMARY KEY, user_id INTEGER, total REAL);
CREATE TABLE shipments (order_id INTEGER PRIMARY KEY, carrier TEXT);

INSERT INTO users VALUES (1, 'Ada'), (2, 'Boris'), (3, 'Cleo');
INSERT INTO orders VALUES (10, 1, 49.99), (11, 2, 99.00);
INSERT INTO shipments VALUES (10, 'UPS');

SELECT u.name, o.total, s.carrier
FROM users AS u
LEFT JOIN orders AS o ON o.user_id = u.id
LEFT JOIN shipments AS s ON s.order_id = o.id;

تعود إلينا ثلاثة مستخدمين. آدا لديها طلب وشحنة. بوريس لديه طلب لكن بدون شحنة (قيمة carrier تساوي NULL). أمّا كليو فليس لديها أي طلب، ولذلك تظهر كلٌّ من o.total وs.carrier بقيمة NULL. سلسلة LEFT JOIN تحافظ على كل مستخدم بصرف النظر عن الموضع الذي تنقطع عنده البيانات في سلسلة العلاقات.

متى يكون LEFT JOIN هو الخيار الصحيح

استخدم LEFT JOIN عندما يكون السؤال في جوهره عن الجدول الأيسر، ويكون الجدول الآخر مجرد معلومات إضافية. صياغات مثل «كل المستخدمين مع طلباتهم إن وُجدت» أو «جميع المنتجات مع آخر تقييم لها» تُترجَم مباشرةً إلى LEFT JOIN.

أمّا INNER JOIN فهو الخيار حين يكون الطرفان مطلوبَين بالقدر نفسه — فعبارة «الطلبات مع بيانات أصحابها» لا معنى لها إذا كان هناك طلب بلا مستخدم، وهنا يكون الفلترة التي يقوم بها الـ inner join هي ما تحتاجه فعلاً.

إذا وجدت نفسك تكتب LEFT JOIN ... WHERE right.col IS NOT NULL، فأنت في الحقيقة كنت تريد INNER JOIN. وإذا وجدت نفسك تكتب LEFT JOIN ... WHERE right.col IS NULL، فأنت تريد anti-join، وقد كتبتَه بشكل صحيح.

التالي: الربط الذاتي (Self-Joins)

أحياناً يكون الجدول الذي تريد الربط معه هو نفس الجدول الذي تستعلم منه أصلاً — الموظفون ومدراؤهم، الأقسام والأقسام الأم، أزواج المستخدمين في المدينة نفسها. هذا ما يُعرف بالربط الذاتي (self-join)، وهو موضوع الصفحة التالية.