JOIN — INNER, LEFT, RIGHT আর FULL

১ · JOIN কেন — ডেটা ইচ্ছে করেই ভাগ করা

পর্ব ১০-এ ER ডায়াগ্রাম থেকে টেবিল বানানোর নিয়ম দেখেছেন: প্রতিটি entity নিজের টেবিলে, আর 1:N সম্পর্ক “N” দিকের টেবিলে একটি foreign key. ফলে একটি অর্ডারের পুরো ছবি — কে কিনলেন, কী কিনলেন, কত দামে — কোনো একটি টেবিলে নেই। গ্রাহকের নাম আছে customers-এ, অর্ডারের তারিখ orders-এ, পণ্যের নাম products-এ। এটি ভুল নয়, পরিকল্পনা: প্রতিটি সত্য এক জায়গায় থাকে, তাই Rahim Uddin-এর ফোন নম্বর বদলাতে একটিই সারি বদলাতে হয়।

এই পর্বে সবচেয়ে বেশি ব্যবহার হবে কোর্সের দোকান ডেটাবেস db-shop: customers (customer_id, name, city, phone, joined_on — ৮ জন), orders (order_id, customer_id, order_date, status — ১০টি অর্ডার), order_items (order_id, product_id, quantity, unit_price — ১৬টি লাইন) আর products (product_id, name, category_id, price, stock — ১০টি পণ্য)। orders.customer_id আঙুল তোলে customers-এর দিকে, আর order_items-এর দুটি কলাম orders আর products-এর দিকে। পরের দিকে বিশ্ববিদ্যালয় ডেটাবেস db-uni-ও লাগবে। প্রতিটি এডিটরের নিচে “নমুনা ডেটা” বাক্সে পুরো ডেটা দেখতে পাবেন।

Join শিখলে আপনি প্রায় যেকোনো ব্যবসায়িক প্রশ্নের উত্তর দিতে পারবেন: “ঢাকার গ্রাহকেরা কোন কোন পণ্য কিনেছেন?”, “কোন পণ্য কখনো বিক্রি হয়নি?”, “কোন কোর্সে এখনো শিক্ষক নেই?” — প্রতিটির উত্তর দুই বা ততোধিক টেবিলে ছড়িয়ে আছে।

২ · Cartesian product থেকে INNER JOIN — সব জোড়া, তারপর ছাঁকনি

Join বোঝার সবচেয়ে পরিষ্কার পথ একটি দুই-ধাপের ছবি। প্রথম ধাপে দুই টেবিলের প্রতিটি সারির সাথে প্রতিটি সারি জোড়া দিন — একে বলে Cartesian product. বাঁ টেবিলে mটি আর ডান টেবিলে nটি সারি থাকলে জোড়া হয় ঠিক m × nটি, কারণ বাঁয়ের প্রতিটি সারি ডানের nটি সারির প্রত্যেকটির সাথে একবার করে বসে। দ্বিতীয় ধাপে শুধু সেই জোড়াগুলো রাখুন, যেখানে শর্ত (যেমন দুই customer_id সমান) সত্য। পর্ব ৩৩-এর relational algebra-র ভাষায়: R ⋈_θ S = σ_θ(R × S). নিচে তিনজন গ্রাহক আর তিনটি অর্ডারের ছোট টেবিলে ধাপ দুটি দেখুন:

INNER JOIN … ON — লেখার নিয়ম

SQL-এ ওপরের দুই ধাপ একটি বাক্যে লেখা হয়: FROM orders INNER JOIN customers ON শর্ত. INNER JOIN শুধু মিল-পাওয়া জোড়া রাখে; INNER শব্দটি ঐচ্ছিক, শুধু JOIN লিখলেও একই। ON-এর পরের অংশটি join condition — সাধারণত foreign key আর primary key সমান হওয়ার শর্ত। সমান (=) চিহ্নের এমন join-কে বলে equi-join.

DBMS ভেতরে কীভাবে মেলায়, তার সবচেয়ে সরল পদ্ধতি দুটি নেস্টেড লুপ: বাঁ টেবিলের প্রতিটি সারি ধরে ডান টেবিলের সব সারির সাথে শর্ত পরীক্ষা। ধাপে ধাপে দেখুন:

এবার আসল db-shop-এ। নিচের এডিটরে তিনটি কোয়েরি: শর্ত ছাড়া জোড়ার সংখ্যা, পুরোনো কমা-লেখায় শর্তসহ সংখ্যা, আর আধুনিক INNER JOIN … ON দিয়ে প্রতিটি অর্ডারের পাশে গ্রাহকের নাম:

-- ১) শর্ত ছাড়া: সব জোড়া (Cartesian product)
SELECT COUNT(*) AS all_pairs FROM customers, orders;
-- ২) পুরোনো কমা-join: শর্ত WHERE-এ
SELECT COUNT(*) AS matched FROM customers, orders
WHERE customers.customer_id = orders.customer_id;
-- ৩) আধুনিক লেখা: INNER JOIN … ON, alias সহ
SELECT o.order_id, o.order_date, c.name, c.city, o.status
FROM orders AS o
INNER JOIN customers AS c ON c.customer_id = o.customer_id
ORDER BY o.order_id;

পুরোনো কমা-join বনাম আধুনিক JOIN

দ্বিতীয় আর তৃতীয় কোয়েরির join একই কাজ করে, আর DBMS দুটিকে সাধারণত একই plan-এ চালায়। কমা দিয়ে টেবিল লিখে শর্ত WHERE-এ দেওয়া SQL-এর প্রথম দিকের রীতি; JOIN … ON আসে ১৯৯২ সালের SQL-92 standard-এ। আজ প্রায় সব style guide আধুনিক লেখাটি পছন্দ করে, তিনটি কারণে:

• শর্ত ভুলে যাওয়া সহজে ধরা পড়ে। পাঁচটি টেবিল কমায় লিখে একটি শর্ত ভুলে গেলে কোনো ত্রুটি আসে না — চুপচাপ Cartesian product, ফল শতগুণ। আধুনিক লেখায় প্রতিটি JOIN-এর পাশে একটি ON থাকার কথা, তাই অভাবটি চোখে পড়ে; PostgreSQL তো ON ছাড়া JOIN-কে সরাসরি syntax error বলে (MySQL আর SQLite অবশ্য সেটিকে CROSS JOIN ধরে চালিয়ে দেয়)।
• সম্পর্ক আর ছাঁকনি আলাদা থাকে। ON-এ লেখা থাকে “টেবিলগুলো কীভাবে যুক্ত”, WHERE-এ “কোন সারি চাই”। পড়তে, রিভিউ করতে সহজ।
• Outer join কমা দিয়ে লেখাই যায় না। LEFT/RIGHT/FULL-এর জন্য JOIN লেখা লাগবেই, তাই এক কোয়েরিতে দুই রীতি না মিশিয়ে সবখানে একটি রাখাই ভালো।

Standard আসার আগে প্রতিটি কোম্পানি নিজের outer join চিহ্ন বানিয়েছিল। পুরোনো কোডে এখনো দেখতে পাবেন — চিনে রাখুন, নতুন করে লিখবেন না:

-- Oracle-এর পুরোনো outer join: (+) চিহ্ন যেদিকে, সেদিকে NULL বসতে পারে
SELECT c.name, o.order_id
FROM customers c, orders o
WHERE c.customer_id = o.customer_id(+);
-- আজকের standard লেখা, একই ফল
SELECT c.name, o.order_id
FROM customers c LEFT JOIN orders o ON o.customer_id = c.customer_id;

Table alias — ছোট নাম

তৃতীয় কোয়েরিতে orders AS o আর customers AS c হলো table alias — কোয়েরির ভেতরে টেবিলের ডাকনাম। AS শব্দটি ঐচ্ছিক (orders o), আর Oracle-এ টেবিল-alias-এর আগে AS লেখাই যায় না, তাই অনেকে AS বাদ দিয়ে অভ্যাস করেন। Alias তিনটি কাজ করে: লেখা ছোট করে; একই নামের কলাম আলাদা করে (দুই টেবিলেই customer_id — শুধু customer_id লিখলে ত্রুটি আসে “ambiguous column name”); আর একই টেবিলকে দুবার ব্যবহার করতে দেয়, যা পর্ব ২০-এর self join-এর ভিত্তি। ভালো অভ্যাস: join থাকলে প্রতিটি কলামের আগে alias লিখুন, এমনকি নাম অনন্য হলেও — কাল কেউ অন্য টেবিলে একই নামের কলাম যোগ করলে কোয়েরি ভাঙবে না।

৩ · তিন-চারটি টেবিল একসাথে — সারি কোথায় গুণ হয়

বাস্তবের প্রশ্নে প্রায়ই চার-পাঁচটি টেবিল লাগে। “Rahim Uddin কোন কোন পণ্য কিনেছেন, কোন অর্ডারে, কত টাকার?” — নাম customers-এ, অর্ডার orders-এ, পরিমাণ আর দাম order_items-এ, পণ্যের নাম products-এ। JOIN একটির পর একটি যোগ হয়: প্রথম দুই টেবিলের join-এর ফলের সাথে তৃতীয় টেবিল, তার ফলের সাথে চতুর্থ। প্রতিটি ধাপে সারির সংখ্যা কী হয়, লক্ষ করুন:

-- Rahim Uddin-এর সব কেনা: চারটি টেবিল
SELECT o.order_id, p.name AS product, oi.quantity,
       oi.quantity * oi.unit_price AS line_total
FROM customers c
JOIN orders o       ON o.customer_id = c.customer_id
JOIN order_items oi ON oi.order_id   = o.order_id
JOIN products p     ON p.product_id  = oi.product_id
WHERE c.name = 'Rahim Uddin'
ORDER BY o.order_id, p.name;

N টেবিল জুড়তে সাধারণত N − 1টি join-শর্ত লাগে — প্রতিটি নতুন টেবিলের জন্য একটি। শর্ত কম হলে কোথাও Cartesian product লুকিয়ে আছে। এটি একটি দ্রুত পরীক্ষা, AI-এর লেখা কোয়েরিতেও কাজে লাগে।

৪ · LEFT JOIN — বাঁ দিকের কেউ বাদ যাবে না

INNER JOIN প্রশ্ন করে “কোন জোড়া মেলে?” কিন্তু অনেক প্রশ্ন আসলে “সব গ্রাহকের তালিকা দাও, অর্ডার থাকলে পাশে লিখে দাও”। এর জন্য outer join, আর সবচেয়ে বেশি ব্যবহৃত রূপ LEFT JOIN (পুরো নাম LEFT OUTER JOIN; OUTER শব্দটি ঐচ্ছিক)। নিয়ম: প্রথমে INNER JOIN-এর মতো সব মিল-পাওয়া জোড়া; তারপর বাঁ টেবিলের যে সারি একটিও জোড়া পায়নি, তাকে একবার যোগ করা — ডান দিকের সব কলামে NULL বসিয়ে।

বিশ্ববিদ্যালয় ডেটাবেসে একই পার্থক্য দেখুন। db-uni-র students (student_id, name, dept_id, batch, cgpa — ৮ জন) আর departments (dept_id, name, building — ৪টি বিভাগ)। Habib Ullah এখনো বিভাগ বাছেননি, তাঁর dept_id NULL:

-- INNER: বিভাগ মিললে তবেই
SELECT s.name, d.name AS dept
FROM students s INNER JOIN departments d ON d.dept_id = s.dept_id
ORDER BY s.student_id;
-- LEFT: সব শিক্ষার্থী, বিভাগ না থাকলে NULL
SELECT s.name, d.name AS dept
FROM students s LEFT JOIN departments d ON d.dept_id = s.dept_id
ORDER BY s.student_id;

যার কিছু নেই — anti-join

“কোন গ্রাহক কখনো অর্ডার করেননি?” আর “কোন পণ্য কখনো বিক্রি হয়নি?” — দুটিই একই ছাঁচ: LEFT JOIN, তারপর WHERE ডান_টেবিলের_NOT_NULL_কলাম IS NULL. মনে রাখবেন = NULL নয়, IS NULL — = NULL সবসময় UNKNOWN, তাই কোনো সারিই আসে না।

-- কোন গ্রাহক কখনো অর্ডার করেননি?
SELECT c.customer_id, c.name
FROM customers c LEFT JOIN orders o ON o.customer_id = c.customer_id
WHERE o.order_id IS NULL;
-- কোন পণ্য কখনো বিক্রি হয়নি?
SELECT p.product_id, p.name, p.stock
FROM products p LEFT JOIN order_items oi ON oi.product_id = p.product_id
WHERE oi.product_id IS NULL;

সবচেয়ে প্রচলিত ফাঁদ — ডান টেবিলের শর্ত WHERE-এ

প্রশ্ন: “প্রত্যেক গ্রাহকের কয়টি delivered অর্ডার? যাঁর একটিও নেই, তাঁর পাশে 0.” স্বাভাবিকভাবে মনে আসে LEFT JOIN, তারপর WHERE o.status = 'delivered'. দুটি লেখা পাশাপাশি চালান:

-- ভুল: ডান টেবিলের শর্ত WHERE-এ
SELECT c.name, COUNT(o.order_id) AS delivered
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.customer_id
WHERE o.status = 'delivered'
GROUP BY c.customer_id, c.name ORDER BY c.customer_id;
-- ঠিক: শর্ত ON-এ, join-এর অংশ হিসেবে
SELECT c.name, COUNT(o.order_id) AS delivered
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.customer_id
                  AND o.status = 'delivered'
GROUP BY c.customer_id, c.name ORDER BY c.customer_id;

৫ · RIGHT JOIN আর FULL OUTER JOIN

RIGHT JOIN হলো LEFT JOIN-এর আয়নার প্রতিবিম্ব: ডান টেবিলের প্রতিটি সারি থাকে, বাঁ দিকে মিল না পেলে NULL. A RIGHT JOIN B আর B LEFT JOIN A একই সারি দেয় (শুধু কলামের ক্রম আলাদা হতে পারে)। তাই বেশিরভাগ দল একটি রীতি মানে: সবসময় LEFT JOIN, যে টেবিলের কাউকে হারানো চলবে না সেটি বাঁয়ে। FULL OUTER JOIN দুই দিকের সবাইকে রাখে: মিল-পাওয়া জোড়া, বাঁয়ের অমিল সারি (ডানে NULL), আর ডানের অমিল সারি (বাঁয়ে NULL). সারির সংখ্যা তাই = INNER-এর সারি + বাঁয়ের অমিল + ডানের অমিল।

db-uni-র courses (course_id, title, dept_id, credits, instructor_id) আর instructors (instructor_id, name, dept_id, salary, mentor_id) নিন। ENG101-এর শিক্ষক এখনো ঠিক হয়নি (instructor_id NULL), আবার একজন শিক্ষক কোনো কোর্স পড়ান না। দুটিই একসাথে দেখতে FULL লাগে:

-- RIGHT: সব কোর্স, শিক্ষক না থাকলে NULL
SELECT c.course_id, c.title, i.name AS instructor
FROM instructors i RIGHT JOIN courses c ON c.instructor_id = i.instructor_id
ORDER BY c.course_id;
-- FULL: সব কোর্স আর সব শিক্ষক
SELECT c.course_id, i.name AS instructor
FROM courses c FULL OUTER JOIN instructors i ON i.instructor_id = c.instructor_id
ORDER BY c.course_id, i.name;

MySQL-এ FULL OUTER JOIN — UNION দিয়ে বানানো

MySQL-এ FULL লিখলে syntax error আসে। প্রচলিত সমাধান: LEFT JOIN-এর ফল, আর তার সাথে উল্টো দিকের anti-join (ডানের যে সারির বাঁয়ে কিছু নেই) — UNION ALL দিয়ে জোড়া। UNION দুই কোয়েরির ফল একটির নিচে আরেকটি বসায় (পর্ব ২২)। নিচের কোয়েরিটি MySQL, PostgreSQL আর SQLite — তিন জায়গাতেই চলে:

-- ভাগ ১: সব কোর্স (শিক্ষক থাকুক বা না থাকুক)
SELECT c.course_id, i.name AS instructor
FROM courses c LEFT JOIN instructors i ON i.instructor_id = c.instructor_id
UNION ALL
-- ভাগ ২: শুধু কোর্সহীন শিক্ষক (anti-join), যাতে কেউ দুবার না আসে
SELECT c.course_id, i.name
FROM instructors i LEFT JOIN courses c ON c.instructor_id = i.instructor_id
WHERE c.course_id IS NULL
ORDER BY 1, 2;

৬ · USING, NATURAL JOIN আর key ছাড়া অন্য কলামে join

USING — একই নামের কলামে join-এর সংক্ষেপ

দুই টেবিলে join-কলামের নাম এক হলে (students.dept_id আর departments.dept_id) লেখা যায় JOIN departments USING (dept_id), যা ON s.dept_id = d.dept_id-এর সমান। বাড়তি সুবিধা: ফলে dept_id কলামটি একবারই থাকে। USING নিরাপদ, কারণ কোন কলাম মেলানো হচ্ছে তা আপনি নিজে লিখে দেন। SQL Server এটি চালায় না; বাকি বড় DBMS-গুলো চালায়।

NATURAL JOIN — সুবিধাজনক, কিন্তু বিপজ্জনক

NATURAL JOIN নিজেই খুঁজে নেয় দুই টেবিলে যত কলামের নাম এক, আর সবগুলোর সমতাকে শর্ত বানায়। কাগজে সুন্দর, বাস্তবে ফাঁদ — শর্তটি কোয়েরিতে লেখা থাকে না, থাকে schema-য়, আর schema বদলায়। db-uni-তে চালিয়ে দেখুন:

-- USING: শুধু dept_id মেলাও
SELECT student_id, s.name, d.name AS dept
FROM students s JOIN departments d USING (dept_id)
ORDER BY student_id;
-- NATURAL: নামের মিল থাকা সব কলাম — কোনগুলো?
SELECT COUNT(*) AS natural_rows FROM students NATURAL JOIN departments;
-- courses-এ আজ dept_id-ই একমাত্র মিল
SELECT COUNT(*) AS before_change FROM courses NATURAL JOIN departments;
-- কেউ courses-এ একটি name কলাম যোগ করলেন…
ALTER TABLE courses ADD COLUMN name TEXT;
SELECT COUNT(*) AS after_change FROM courses NATURAL JOIN departments;

key নয় এমন কলামে join — আর অসমতার শর্ত

Join-শর্ত FK = PK হতেই হবে, এমন কোনো নিয়ম নেই — যেকোনো সত্য-মিথ্যা শর্ত চলে। যেমন দামের ভিত্তিতে পণ্যকে শ্রেণিতে ফেলা: একটি ছোট টেবিল price_bands (band, min_price, max_price) — Budget 0–999, Mid 1000–4999, Premium 5000–1000000 টাকা — এডিটরের সাথে তৈরি হয়। শর্তে = নেই, আছে BETWEEN; এমন join-কে বলে theta join বা non-equi join:

-- দামের পরিসরে join
SELECT b.band, COUNT(*) AS products, MIN(p.price) AS cheapest, MAX(p.price) AS costliest
FROM products p
JOIN price_bands b ON p.price BETWEEN b.min_price AND b.max_price
GROUP BY b.band ORDER BY MIN(p.price);
-- কেউ একটি পরিসর যোগ করলেন, যা Mid-এর সাথে মিশে যায়
INSERT INTO price_bands VALUES ('Gift', 1000, 2500);
SELECT COUNT(*) AS rows_now
FROM products p
JOIN price_bands b ON p.price BETWEEN b.min_price AND b.max_price;

৭ · Fan-out — join-এর পর যোগফল দ্বিগুণ

অংশ ৩-এ দেখেছেন: orders থেকে order_items-এ গেলে প্রতিটি অর্ডার-সারি তার লাইনের সংখ্যা যতবার, ততবার আসে। লাইন-স্তরের হিসাব (পরিমাণ × দাম) তাতে ঠিকই থাকে, কারণ প্রতিটি লাইন একবারই আছে। কিন্তু অর্ডার-স্তরের কোনো সংখ্যা — ডেলিভারি চার্জ, অর্ডারের ছাড়, পরিশোধিত টাকা — এখন বারবার এসেছে। তার ওপর SUM চালালে ফল গুণ হয়ে যায়। একে বলে fan-out: এক সারি পাখার মতো ছড়িয়ে অনেক সারি। ধরুন প্রতিটি অর্ডারে ৬০ টাকা ডেলিভারি চার্জ (একটি delivery_fee কলাম); Karima Begum-এর দুটি অর্ডার, প্রতিটিতে দুটি লাইন:

এডিটরের সাথে orders টেবিলে delivery_fee কলাম যোগ হয় (সব অর্ডারে ৬০)। প্রথম কোয়েরি ফাঁদটি দেখায়, দ্বিতীয়টি সমাধান। দ্বিতীয়টির FROM-এ বন্ধনীর ভেতরের SELECT হলো একটি derived table — একটি কোয়েরির ফলকে টেবিলের মতো ব্যবহার; বিস্তারিত পর্ব ২১-এ, আর একই কাজ CTE দিয়ে পর্ব ২৫-এ।

-- ফাঁদ: লাইনের সাথে join করে অর্ডার-স্তরের চার্জ যোগ
SELECT c.name, COUNT(*) AS rows_seen, SUM(o.delivery_fee) AS fees_wrong,
       SUM(DISTINCT o.delivery_fee) AS fees_distinct
FROM customers c
JOIN orders o       ON o.customer_id = c.customer_id
JOIN order_items oi ON oi.order_id   = o.order_id
WHERE c.customer_id IN (1, 2) GROUP BY c.customer_id, c.name;
-- সমাধান: আগে অর্ডার-প্রতি লাইনের যোগ, তারপর join
SELECT c.name, COUNT(*) AS orders, SUM(o.delivery_fee) AS fees, SUM(t.items) AS items
FROM customers c
JOIN orders o ON o.customer_id = c.customer_id
JOIN (SELECT order_id, SUM(quantity * unit_price) AS items
      FROM order_items GROUP BY order_id) t ON t.order_id = o.order_id
WHERE c.customer_id IN (1, 2) GROUP BY c.customer_id, c.name;

৮ · Venn diagram-এর সীমা, আর join-এর গতি

Join আসলে Venn diagram নয়

ইন্টারনেটে join বোঝাতে প্রায়ই দুটি মেশানো বৃত্ত আঁকা হয়: INNER মানে মাঝের অংশ, LEFT মানে বাঁ বৃত্ত পুরোটা। প্রথম অনুভূতির জন্য ছবিটি মন্দ নয়, কিন্তু এটি তিনটি জায়গায় ভুল শেখায়:

Venn diagram আসলে মানায় পর্ব ২২-এর UNION, INTERSECT আর EXCEPT-এ, যেখানে দুই কোয়েরির ফল একই গঠনের সারির set. Join-এর জন্য সঠিক মানসিক ছবি এই পর্বের স্টেপারগুলো: বাঁয়ের প্রতিটি সারি ধরে ডানে মিল খোঁজা, যতগুলো মেলে ততগুলো জোড়া, আর outer join-এ মিল না পেলে একটি NULL-জোড়া।

Join দ্রুত হয় কীভাবে — একটি প্রাথমিক ধারণা

অংশ ২-এর সরল নেস্টেড লুপে তুলনা হয় m × nটি — দুই টেবিলে এক লাখ করে সারি থাকলে ১০০০ কোটি তুলনা। কিন্তু ডান টেবিলের join-কলামে index (সাধারণত B+ tree) থাকলে বাঁয়ের প্রতিটি সারির জন্য পুরো ডান টেবিল না ঘুরে index-এ খোঁজা যায়, যার খরচ মোটামুটি log n-এর সমানুপাতিক। মোট খরচ তখন প্রায় m × log n + মিল-পাওয়া সারির সংখ্যা — এক লাখ সারিতে ২০-এর কাছাকাছি ধাপ, এক লাখ নয়। একে বলে index nested loop join. এর বাইরে বড় টেবিলের জন্য আছে hash join (ছোট টেবিল দিয়ে একটি hash table বানিয়ে বড়টি একবার পড়া) আর sort-merge join; কোনটি কখন বাছা হয় আর তার I/O খরচ — পর্ব ৪২-এ।

ব্যবহারিক শিক্ষাটি এখনই নিন: foreign key কলামে index রাখুন। join প্রায় সবসময় FK = PK, আর PK-তে index নিজে থেকেই থাকে, কিন্তু FK-তে সব DBMS নিজে বানায় না:

-- SQLite আর PostgreSQL FK কলামে নিজে index বানায় না — নিজে বানান
CREATE INDEX idx_orders_customer   ON orders(customer_id);
CREATE INDEX idx_items_product     ON order_items(product_id);
-- order_items(order_id, product_id)-এর primary key-ই order_id দিয়ে খোঁজায় কাজে লাগে
-- MySQL (InnoDB) FK-র জন্য index না থাকলে নিজেই একটি বানিয়ে নেয়

index ফল বদলায় না, শুধু গতি — তাই ছোট নমুনা ডেটায় পার্থক্য দেখবেন না। পর্ব ৪০–৪১-এ index আর EXPLAIN দিয়ে plan পড়া শিখবেন।

৯ · AI-এর যুগে JOIN

AI-কে “প্রত্যেক গ্রাহকের মোট খরচ দেখাও” বললে কয়েক সেকেন্ডে একটি চার-টেবিলের join পাবেন, আর সেটি চলবেও। সমস্যা হলো, join-এর ভুল প্রায় কখনো ত্রুটি দেয় না — দেয় ভুল সংখ্যা, দেখতে একদম স্বাভাবিক। AI-এর লেখা join-এ যা প্রায়ই দেখা যায়:

AI-এর লেখা join হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি কলামের নাম আমার schema-তে আছে, আর প্রতিটি কলামের আগে alias
• N টেবিলের জন্য অন্তত N − 1টি join-শর্ত; কোথাও কমা দিয়ে লুকানো Cartesian product নেই
• “সবাই” চাইলে যেই টেবিলের কেউ বাদ যাবে না, সেটি LEFT JOIN-এর বাঁয়ে; ডান টেবিলের শর্ত ON-এ
• প্রতিটি join যোগের আগে-পরে COUNT(*) দেখেছি; সারি বাড়লে প্রতিটি SUM/COUNT সেই grain-এর কি না যাচাই করেছি
• NULL FK (Habib-এর মতো), অর্ডারহীন গ্রাহক (Tanvir-এর মতো) আর একই মানের দুটি সারি দিয়ে প্রান্তিক ক্ষেত্র পরীক্ষা করেছি
• একজন গ্রাহক বা একটি অর্ডারের সংখ্যা হাতে হিসাব করে কোয়েরির ফলের সাথে মিলিয়েছি
• বড় টেবিলে চালানোর আগে FK কলামে index আছে কি না আর EXPLAIN-এ plan দেখেছি