SQL output prediction — কোয়েরির ফল হাতে বের করা

name
Rina
Tania
Lipi
Babu        (৪টি সারি)

Rina আর Babu বেতনের শর্তে আসেন, Tania বিভাগের শর্তে। মূল প্রশ্ন Lipi: NULL > 40000 হলো UNKNOWN, কিন্তু UNKNOWN OR TRUE = TRUE, তাই তিনি আসেন। Kamal-এর বেলায় FALSE OR UNKNOWN = UNKNOWN — বাদ।

(১)  name  │ salary          (২)  name  │ salary
     Babu  │ 50000                Sumon │ 40000
     Rina  │ 50000                Tania │ 40000
     Sumon │ 40000

(১)-এ 50000-এর টাই নাম দিয়ে ভাঙে — Babu, Rina. 40000-এ Sumon আর Tania, নামের ক্রমে Sumon আগে, আর LIMIT 3 সেখানেই থামে। (২)-তে SQLite NULL-কে সবচেয়ে ছোট ধরে, তাই ছোট থেকে বড় ক্রম: Lipi (NULL), Kamal, Sumon, Tania, Rina, Babu. প্রথম দুটি বাদ দিয়ে পরের দুটি: Sumon, Tania.

PostgreSQL-এ: NULL-কে সবচেয়ে বড় ধরা হয়। (১)-এ Lipi প্রথমে চলে আসেন: Lipi, Babu, Rina. (২)-এর ক্রম Kamal, Sumon, Tania, Rina, Babu, Lipi — ফল Tania, Rina. MySQL আর SQL Server SQLite-এর মতো (NULL ছোট)। সব জায়গায় এক ফল চাইলে NULLS LAST লিখুন (PostgreSQL, Oracle, SQLite 3.30+).

SELECT name, salary FROM emp ORDER BY salary DESC, name LIMIT 3;
SELECT name, salary FROM emp ORDER BY salary, id LIMIT 2 OFFSET 2;

-- PostgreSQL-এর মতো ক্রম চাইলে:
SELECT name, salary FROM emp ORDER BY salary DESC NULLS FIRST, name LIMIT 3;

(১) ৩টি সারি: CSE, EEE আর NULL. DISTINCT সব NULL-কে একে অপরের “সমান” ধরে একটি সারি রাখে। (২) 2 | 5: COUNT(DISTINCT dept) NULL গোনে না, তাই 2; COUNT(dept) পাঁচটি অ-NULL মান গোনে। অর্থাৎ (১)-এর সারির সংখ্যা আর (২)-এর প্রথম মান আলাদা — NULL-এর জন্য। (৩) ৫টি সারি: (CSE, 50000) জোড়া দুবার আছে (Rina, Babu), বাকি চারটি জোড়া আলাদা। DISTINCT পুরো সারি তুলনা করে, প্রথম কলাম নয়।

name  │ band │ d1   │ d2
Kamal │ low  │ NULL │ none
Lipi  │ low  │ EEE  │ EEE

Lipi-র বেতন NULL — দুটি WHEN-ই UNKNOWN, আর CASE শুধু TRUE-তে থামে, তাই ELSE-এ গিয়ে 'low'. “বেতন জানা নেই” আর “কম বেতন” এক হয়ে গেল — রিপোর্টে এটি বড় ভুল। Kamal-এর d1: simple CASE ভেতরে dept = NULL তুলনা করে, যা কখনো TRUE নয়; তাই ELSE dept, অর্থাৎ NULL. NULL ধরতে d2-র মতো WHEN dept IS NULL লিখতে হয় — সব DBMS-এ একই।

(১)  3 │ 3.5 │ 1 │ -3 │ 3.5
(২)  1.6666666666666667 │ 1 │ 1.6666666666666667 │ 1.67

দুটি পূর্ণসংখ্যার ভাগ পূর্ণসংখ্যা — integer division, ভগ্নাংশ কেটে ফেলা হয়। ঋণাত্মক সংখ্যায় কাটা হয় শূন্যের দিকে, তাই −7/2 = −3 (Python-এর // দিত −4). একটি দিকও দশমিক হলে ফল দশমিক। (২)-এ AVG সবসময় দশমিক দেয়, কিন্তু নিজে SUM/COUNT লিখলে 5/3 = 1 — গড় হিসাবের খুব প্রচলিত বাগ। * 1.0 দিয়ে আগে দশমিকে নিলে ঠিক হয়।

অন্য DBMS-এ: PostgreSQL আর SQL Server-এ 7/2 = 3 (একই)। MySQL-এ / সবসময় দশমিক ভাগ — 7/2 = 3.5000; পূর্ণসংখ্যার ভাগের জন্য 7 DIV 2. Oracle-এ 7/2 = 3.5. তাই প্রশ্নে DBMS-এর নাম না থাকলে উত্তরে লিখুন, কোনটি ধরেছেন।

DHAKA │ 4 │ Data │ base │ NULL │ hi │ abc

SQLite-এর LENGTH লেখার অক্ষর (Unicode character) গোনে: “ঢাকা” = ঢ, া, ক, া — ৪টি। SUBSTR-এ অবস্থান 1 থেকে শুরু; ঋণাত্মক শুরু মানে শেষ থেকে গোনা। 'abc' || NULL হলো NULL — NULL propagation: NULL-এর সাথে যেকোনো হিসাব NULL.

অন্য DBMS-এ: MySQL-এ LENGTH বাইট গোনে — UTF-8-এ প্রতিটি বাংলা অক্ষর ৩ বাইট, তাই 12; অক্ষর গুনতে CHAR_LENGTH. MySQL-এ ডিফল্টভাবে || হলো যৌক্তিক OR (জোড়া লাগাতে CONCAT). Oracle-এ 'abc' || NULL হয় 'abc', কারণ Oracle ফাঁকা string আর NULL-কে একই ধরে।

2025-03-03 │ 28.0 │ 09 │ text │ 2025-08-31

SQLite '+1 month' দিলে মাসের ঘর এক বাড়িয়ে 2025-02-31 বানায়, তারপর সেটিকে স্বাভাবিক করে — ফেব্রুয়ারির ২৮ দিনের পরে আরও ৩ দিন, অর্থাৎ ৩ মার্চ। ২০২৫ অধিবর্ষ নয়, তাই ফেব্রুয়ারি ২৮ দিনের, পার্থক্য 28.0. strftime লেখা (text) দেয় — '09', সংখ্যা 9 নয়; তাই strftime('%m', d) = 9 লিখলে কোনো সারি মিলবে না। শেষটি: মাসের শুরু (০১ সেপ্টেম্বর) থেকে এক দিন পেছনে — আগের মাসের শেষ দিন।

অন্য DBMS-এ: PostgreSQL-এ DATE '2025-01-31' + INTERVAL '1 month' আর MySQL-এ DATE_ADD('2025-01-31', INTERVAL 1 MONTH) দুটিই মাসের শেষ দিনে আটকে 2025-02-28 দেয়। বিল বা কিস্তির তারিখ হিসাবে এই পার্থক্য সরাসরি টাকার হিসাব বদলে দিতে পারে।

(১) 1 — SQLite-এর LIKE ইংরেজি (ASCII) অক্ষরে বড়-ছোট হাতের পার্থক্য করে না, তাই 'r%' মেলে Rina-র সাথে। PostgreSQL-এর LIKE পার্থক্য করে — সেখানে 0 (ILIKE দিলে 1). (২) 1 | 0 — দুটি text তুলনা হয় অভিধানের মতো অক্ষর ধরে: '1' < '9', তাই '10' < '9' সত্য (1); সংখ্যা হিসেবে 10 < 9 মিথ্যা (0). (৩) 10, 100, 9 — text হিসেবে সাজানো। (৪) 9, 10, 100 — সংখ্যায় রূপান্তর করে সাজানো। রোল নম্বর বা কোড TEXT কলামে রাখলে এই ফাঁদ প্রায়ই দেখা যায়।

-- ফ-০৫ থেকে ফ-০৮: ভাগ, string, তারিখ আর text-তুলনা
SELECT 7/2, 7/2.0, -7/2, AVG(v), SUM(v)/COUNT(v) FROM m;
SELECT LENGTH('ঢাকা') AS len, 'abc' || NULL AS joined,
       date('2025-01-31', '+1 month') AS next_month,
       typeof(strftime('%m', '2025-09-15')) AS t;
SELECT '10' < '9' AS text_cmp, 10 < 9 AS num_cmp;
SELECT c FROM codes ORDER BY c;

(১) 0 — dept = NULL প্রতিটি সারিতে UNKNOWN, Kamal-এর সারিতেও। কোনো ত্রুটি হয় না, তাই ভুলটি চোখে পড়ে না। (২) Kamal — NULL খোঁজার একমাত্র ঠিক পথ IS NULL. (৩) Tania, Lipi — Kamal আসেন না, কারণ NULL <> 'CSE'-ও UNKNOWN. “CSE ছাড়া সবাই” বললে মানুষ Kamal-কে ধরেন, SQL ধরে না; চাইলে OR dept IS NULL যোগ করতে হয়।

(১)  6 │ 5 │ 5 │ 3
(২)  42000.0 │ 35000 │ 35000.0

COUNT(*) সারি গোনে (৬); COUNT(কলাম) শুধু অ-NULL মান (dept-এ Kamal বাদ, salary-তে Lipi বাদ — দুটিই ৫); COUNT(DISTINCT salary) আলাদা মান গোনে: 50000, 40000, 30000 — ৩। (২)-এ AVG NULL বাদ দিয়ে 210000 ÷ 5 = 42000. কিন্তু SUM ÷ COUNT(*) মানে 210000 ÷ 6 = 35000 — Lipi-কে শূন্য বেতনের কর্মী ধরা হলো। COALESCE(salary, 0) একই কাজ খোলাখুলি করে। কোনটি ঠিক, তা ব্যবসার প্রশ্ন: “জানা বেতনের গড়” নাকি “মাথাপিছু খরচ”। পরীক্ষায় দুটির পার্থক্য লিখলেই পূর্ণ নম্বর।

SELECT COUNT(*), COUNT(dept), COUNT(salary),
       COUNT(DISTINCT salary)
FROM emp;

SELECT AVG(salary), SUM(salary)/COUNT(*),
       AVG(COALESCE(salary, 0))
FROM emp;

NULL │ 1 │ 0 │ NULL │ 1 │ NULL │ NULL │ NULL │ 3 │ NULL │ 5

মনে রাখার কৌশল: UNKNOWN-কে “হয়তো সত্য, হয়তো মিথ্যা” ভাবুন। NULL AND 0 — একটি দিক নিশ্চিত মিথ্যা, তাই পুরোটাই মিথ্যা (0). NULL OR 1 — একটি দিক নিশ্চিত সত্য, তাই সত্য (1). বাকি ক্ষেত্রে উত্তর অজানাই থাকে। NOT UNKNOWN-ও UNKNOWN. NULLIF(a, b) সমান হলে NULL দেয়, না হলে a — ভাগে শূন্য এড়াতে কাজে লাগে: x / NULLIF(y, 0).

(১) কোনো সারি নেই। (২) BBA. (৩) CSE, EEE.

(১)-এর subquery-র তালিকা: CSE, CSE, EEE, NULL, EEE, CSE. BBA-র জন্য 'BBA' NOT IN (…, NULL) মানে 'BBA' <> 'CSE' AND … AND 'BBA' <> NULL. শেষ অংশটি UNKNOWN, আর TRUE AND UNKNOWN = UNKNOWN — তাই BBA বাদ। তালিকায় একটি NULL থাকলেই NOT IN কখনো TRUE হয় না। (২) anti-join-এর নিরাপদ রূপ: NOT EXISTS শুধু দেখে “মেলে এমন সারি আছে কি না”, আর NULL কারও সাথে মেলে না। (৩) IN-এ সমস্যা নেই: সমান একটি মান পেলেই TRUE.

-- ১. ফাঁদ: subquery-তে NULL
SELECT code FROM dept WHERE code NOT IN (SELECT dept FROM emp);

-- ২. নিরাপদ: NOT EXISTS
SELECT code FROM dept d
WHERE NOT EXISTS (SELECT 1 FROM emp e WHERE e.dept = d.code);

-- ৩. NOT IN রাখতে চাইলে NULL ছেঁকে নিন
SELECT code FROM dept
WHERE code NOT IN (SELECT dept FROM emp WHERE dept IS NOT NULL);

NULL │ 0 │ NULL │ NULL │ 0          (১টি সারি)

GROUP BY ছাড়া aggregate কোয়েরি সবসময় ঠিক একটি সারি দেয়, WHERE কোনো সারি না রাখলেও। খালি সেটে COUNT 0, কিন্তু SUM, MAX, AVG NULL — “শূন্য টাকা” নয়, “যোগ করার কিছু নেই”। রিপোর্টে 0 দেখাতে চাইলে COALESCE(SUM(salary), 0). SQLite-এর নিজস্ব TOTAL(salary) খালি সেটে 0.0 দেয় — এটি standard নয়, অন্য DBMS-এ নেই।

2, 3, 4. প্রথম দুটির যোগফল ৫, ৬ নয়। Lipi-র জন্য শর্তটি UNKNOWN, আর NOT UNKNOWN-ও UNKNOWN — তাই তিনি কোনো দলেই নেই। একটি শর্ত আর তার NOT মিলে টেবিলকে দুই ভাগ করে না, তিন ভাগ করে: TRUE, FALSE আর UNKNOWN. তৃতীয় কোয়েরি IS NOT TRUE দিয়ে FALSE আর UNKNOWN দুটিই ধরে — 4 (Sumon, Tania, Kamal, Lipi). IS TRUE/IS NOT TRUE SQLite (3.23+) আর PostgreSQL-এ চলে; SQL Server-এ নেই।

dept │ n │ total
NULL │ 1 │ 30000
CSE  │ 3 │ 140000
EEE  │ 2 │ 40000

তিনটি দল — GROUP BY সব NULL-কে একটি দলে রাখে, আর SQLite ছোট থেকে বড় সাজালে NULL আগে আসে (PostgreSQL-এ শেষে)। EEE-র total 40000: SUM Lipi-র NULL বাদ দিয়েছে, কিন্তু n = 2, কারণ COUNT(*) সারি গোনে। BBA নেই — emp-এ তার কোনো সারিই নেই; BBA দেখাতে dept থেকে LEFT JOIN লাগত।

(১) CSE 3, EEE 2. (২) শুধু CSE 3 — EEE-তে অ-NULL বেতন একটিই (Tania). (৩) CSE 3, EEE 1 — WHERE আগে চলে সারি ছাঁকে: Kamal (30000) আর Lipi (NULL) বাদ, তারপর দল। NULL দল নেই, কারণ তার একমাত্র সারি (Kamal) আগেই বাদ। নিয়ম: “কোন সারি গোনা হবে” → WHERE; “কোন দল দেখানো হবে” → HAVING.

dept │ name  │ MIN(salary)
NULL │ Kamal │ 30000
CSE  │ Sumon │ 40000
EEE  │ Tania │ 40000

name GROUP BY-তে নেই, aggregate-এর ভেতরেও নেই — একে বলে bare column. SQLite এটি চালায়, আর একটি বিশেষ নিয়ম মানে: কোয়েরিতে একটিমাত্র MIN বা MAX থাকলে bare column আসে সেই সারি থেকে, যেখানে MIN/MAX পাওয়া গেছে। তাই CSE-তে Sumon (40000). MIN NULL বাদ দেয়, তাই EEE-তে Tania. MIN/MAX না থাকলে (যেমন COUNT) কোন সারির নাম আসবে, তা অনির্দিষ্ট।

অন্য DBMS-এ: PostgreSQL, SQL Server আর Oracle ত্রুটি দেয় — PostgreSQL-এর বার্তা: name কলামটি GROUP BY-তে থাকতে হবে বা aggregate-এ ব্যবহার করতে হবে। MySQL 5.7.5 থেকে ডিফল্ট ONLY_FULL_GROUP_BY মোডে একই রকম ত্রুটি দেয়। পরীক্ষায় “কী আসবে” জিজ্ঞেস করলে standard SQL-এর উত্তর: ত্রুটি।

-- SQLite-এর bare column: MIN-এর সারি থেকে name
SELECT dept, name, MIN(salary) FROM emp GROUP BY dept ORDER BY dept;

-- বহনযোগ্য পথ: window function দিয়ে প্রতি বিভাগে সর্বনিম্ন বেতনের সবাই
WITH r AS (
  SELECT dept, name, salary,
         RANK() OVER (PARTITION BY dept ORDER BY salary) AS rk
  FROM emp WHERE salary IS NOT NULL)
SELECT dept, name, salary FROM r WHERE rk = 1 ORDER BY dept;

(১) ১টি সারি: 0 | NULL. GROUP BY নেই, তাই পুরো (খালি) টেবিল একটি দল। (২) ০টি সারি। GROUP BY থাকলে দল তৈরি হয় সারি থেকে — সারি নেই, দলও নেই, তাই “COUNT = 0” লেখা কোনো সারিও নেই। (৩) ০টি সারি। পুরো টেবিল একটি দল (COUNT 6), HAVING সেটি বাদ দেয়। SQLite-এ GROUP BY ছাড়া HAVING চলে 3.39.0 থেকে; পুরোনো সংস্করণে ত্রুটি দিত। PostgreSQL-এ চলে।

status    │ n
delivered │ 5
pending   │ 2
shipped   │ 2

চারটি দল: delivered ৫, shipped ২, pending ২, cancelled ১. HAVING cancelled বাদ দেয়। pending আর shipped-এর টাই status দিয়ে ভাঙে — বর্ণানুক্রমে pending আগে। ORDER BY-তে n — SELECT-এর alias — ব্যবহার করা যায়, কারণ ORDER BY চলে SELECT-এর পরে।

4, 6, 6, 8, 16. a-র দুটি 2 প্রতিটি b-র দুটি 2-এর সাথে মেলে: 2 × 2 = 4 — এটিই INNER. NULL = NULL TRUE নয়, তাই দুই দিকের NULL কারও সাথে মেলে না। LEFT: 4 + (a-র 1) + (a-র NULL) = 6. RIGHT: 4 + (b-র 3) + (b-র NULL) = 6. FULL: 4 + দুই দিকের অমিল ২ + ২ = 8. CROSS: 4 × 4 = 16, শর্ত নেই। সূত্র: FULL = INNER + বাঁয়ের অমিল + ডানের অমিল।

SELECT 'INNER' AS j, COUNT(*) AS n FROM a JOIN b ON a.x = b.x
UNION ALL SELECT 'LEFT',  COUNT(*) FROM a LEFT  JOIN b ON a.x = b.x
UNION ALL SELECT 'RIGHT', COUNT(*) FROM a RIGHT JOIN b ON a.x = b.x
UNION ALL SELECT 'FULL',  COUNT(*) FROM a FULL  JOIN b ON a.x = b.x
UNION ALL SELECT 'CROSS', COUNT(*) FROM a CROSS JOIN b;

-- FULL JOIN-এর ৮টি সারি নিজের চোখে
SELECT a.x AS ax, b.x AS bx FROM a FULL JOIN b ON a.x = b.x;

9 আর 5. delivered অর্ডার: Rahim ১টি, Karima ২টি, Nusrat ১টি, Imran ১টি। প্রথম কোয়েরিতে শর্তটি “কোন অর্ডার জুড়ব” ঠিক করে, কোনো গ্রাহক বাদ দেয় না: ১ + ২ + ১ + ১ = ৫ সারি, আর বাকি চারজন (Sabbir, Tanvir, Farhana, Mitu) একটি করে NULL-সারি — মোট ৯. দ্বিতীয়টিতে WHERE চলে JOIN-এর পরে; NULL-সারিতে o.status = 'delivered' UNKNOWN, তাই সেগুলো বাদ — LEFT JOIN কার্যত INNER JOIN হয়ে যায়: ৫.

-- শর্ত ON-এ: সব গ্রাহক থাকেন
SELECT c.name, o.order_id
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.customer_id
                  AND o.status = 'delivered'
ORDER BY c.customer_id, o.order_id;

-- শর্ত WHERE-এ: NULL-সারি বাদ
SELECT COUNT(*) FROM customers c
LEFT JOIN orders o ON o.customer_id = c.customer_id
WHERE o.status = 'delivered';

Tanvir: a = 1, b = 0. Rahim: a = 3, b = 3. LEFT JOIN Tanvir-এর জন্য একটি NULL-সারি বানায়; COUNT(*) সেটিকে গোনে, COUNT(o.order_id) গোনে না। “প্রতিটি গ্রাহকের অর্ডার কয়টি” প্রশ্নে COUNT(*) লিখলে অর্ডারহীন সবার পাশে 1 আসে — ভুল, অথচ দেখতে বিশ্বাসযোগ্য। মোট ৮টি সারি: Karima 2 | 2, বাকি পাঁচজন 1 | 1.

name │ rows_ │ paid
Arif │ 6     │ 12000        (১টি সারি — Bristy নেই)

আসল জমা 6000, কিন্তু কোয়েরি বলে 12000. Arif-এর ২টি ফোন আর ৩টি ফি একে অপরের সাথে কোনো সম্পর্ক ছাড়াই জোড়া লাগে: ২ × ৩ = ৬ সারি, প্রতিটি ফি দুবার যোগ হয়। দুটি স্বাধীন one-to-many সম্পর্ক একসাথে JOIN করলেই এই দ্বিগুণ-গোনা — fan-out-এর সবচেয়ে ক্ষতিকর রূপ। Bristy-র ফোন নেই, তাই INNER JOIN-এ তিনি পুরোই হারিয়ে গেছেন। সমাধান: আগে প্রতিটি সম্পর্ক আলাদা করে aggregate করুন (subquery/CTE), তারপর জুড়ুন।

-- ফাঁদ: দুই one-to-many একসাথে
SELECT s.name, COUNT(*) AS rows_, SUM(f.amount) AS paid
FROM s JOIN phone p ON p.sid = s.id
       JOIN fee f   ON f.sid = s.id
GROUP BY s.id;

-- ঠিক: ফি আলাদা করে যোগ, ফোন আলাদা করে গোনা
SELECT s.name,
       (SELECT SUM(amount) FROM fee   WHERE sid = s.id) AS paid,
       (SELECT COUNT(*)    FROM phone WHERE sid = s.id) AS phones
FROM s ORDER BY s.id;

3 আর 6. INNER-এ শুধু যাঁদের mentor আছে: Shahana → Anisur, Rumana → Mahbub, Tasnim → Shahana. LEFT-এ ছয়জনই, বাকি তিনজনের পাশে mentor-এর নাম NULL. একই টেবিলকে দুটি নাম (i আর m) দিলে DBMS দুটিকে আলাদা টেবিলের মতোই দেখে।

0 আর 7. NATURAL JOIN একই নামের সব কলামে মেলায় — এখানে dept_id আর name দুটিই। শর্তটি হয়ে যায় “শিক্ষার্থীর নাম = বিভাগের নাম”, যা কারও বেলায় সত্য নয়। USING (dept_id) শুধু একটি কলামে মেলায়: Habib-এর NULL কোনো বিভাগের সাথে মেলে না, বাকি ৭ জন মেলেন। শিক্ষা: পরে কেউ কোনো টেবিলে একই নামের কলাম যোগ করলে NATURAL JOIN-এর অর্থ নিঃশব্দে বদলে যায় — তাই বাস্তবে এটি এড়ানো হয়।

7, 10, 7. IN হলো semi join: প্রতিটি গ্রাহক একবারই আসেন, যতগুলো অর্ডারই থাকুক। JOIN অর্ডার ধরে সারি বানায় — Rahim ৩ বার, Karima ২ বার — তাই ১০, যা আসলে অর্ডারের সংখ্যা। COUNT(DISTINCT …) দিয়ে আবার ৭-এ ফেরা যায়, কিন্তু এর মানে আগে অপ্রয়োজনে সারি বাড়ানো হয়েছিল। “আছে কি না” প্রশ্নে IN বা EXISTS স্বাভাবিক পছন্দ।

Rina, Babu. ভেতরের scalar subquery একবার চলে: AVG = 42000 (NULL বাদ দিয়ে, ফ-১০)। 42000-এর বেশি শুধু দুজন 50000. AVG-কে 35000 ভাবলে Sumon আর Tania-ও আসতেন — তাই গড়টি আগে ঠিক করুন।

Rina, Babu. এটি correlated subquery — বাইরের প্রতিটি সারির জন্য আবার চলে। CSE-র গড় 140000 ÷ 3 ≈ 46666.67: Rina আর Babu বেশি, Sumon কম। EEE-র গড় 40000 (Lipi-র NULL বাদ): Tania-র 40000 সমান, বেশি নয়; Lipi-র NULL তুলনা UNKNOWN. Kamal-এর বেলায় ভেতরে e2.dept = NULL — কোনো সারি মেলে না, AVG খালি সেটে NULL, আর 30000 > NULL UNKNOWN. অথচ GROUP BY দিয়ে দেখলে NULL দলের গড় 30000! GROUP BY NULL-কে দল বানায়, কিন্তু = দিয়ে মেলানো subquery NULL-কে মেলায় না।

-- প্রতিটি কর্মীর পাশে তাঁর বিভাগের গড় (correlated)
SELECT name, dept, salary,
       (SELECT ROUND(AVG(salary), 2) FROM emp e2
        WHERE e2.dept = e.dept) AS dept_avg
FROM emp e ORDER BY id;

-- GROUP BY-তে NULL নিজেই একটি দল
SELECT dept, ROUND(AVG(salary), 2) AS avg_sal
FROM emp GROUP BY dept;

SQLite: Rina, তারপর NULL. SQLite scalar subquery-র প্রথম সারিটি নেয়, বাকিগুলো নিঃশব্দে ফেলে দেয়; কোনো সারি না পেলে NULL. PostgreSQL: প্রথমটিতে ত্রুটি — expression হিসেবে ব্যবহৃত subquery একাধিক সারি দিয়েছে। MySQL, SQL Server আর Oracle-ও ত্রুটি দেয়। দ্বিতীয়টি সবখানে NULL. SQLite-এ পরীক্ষা করা কোয়েরি অন্য DBMS-এ ভেঙে যাওয়ার একটি পরিচিত কারণ এটি।

4, 9, 2. UNION সব ডুপ্লিকেট সরায়: NULL, BBA, CSE, EEE — ৪টি (NULL একবার)। UNION ALL কিছুই সরায় না: ৬ + ৩ = ৯. INTERSECT: দুই দিকেই আছে CSE আর EEE. UNION-এর ফলের ক্রম নিশ্চিত নয় (SQLite ডুপ্লিকেট সরাতে সাজায় বলে প্রায়ই সাজানো দেখায়) — ক্রম চাইলে শেষে ORDER BY. দ্রুততার দিক থেকেও পার্থক্য আছে: UNION-কে ডুপ্লিকেট খুঁজতে সাজাতে বা hash করতে হয়, UNION ALL শুধু জোড়া লাগায়।

(১) BBA. (২) একটি সারি: NULL. EXCEPT তুলনা করে “আলাদা কি না” দিয়ে, যেখানে দুটি NULL আলাদা নয় — তাই emp-এর NULL বাঁ দিকের BBA-কে আটকায় না, আর (১) ঠিক উত্তর দেয়। (২)-এ Kamal-এর NULL কোনো বিভাগের code নয়, তাই সেটিই একমাত্র “বাড়তি” মান। একই প্রশ্ন, তিন রকম লেখা, তিন রকম NULL-নিয়ম: NOT IN ফাঁদে পড়ে, NOT EXISTS আর EXCEPT পড়ে না।

প্রথমটি ৭টি সারি: 1, 2, 4, 8, 16, 32, 64. শর্ত দেখা হয় আগের সারির ওপর: i = 32 < 50 সত্য, তাই 64 তৈরি হয় — ৫০ পেরিয়েও। তারপর 64 < 50 মিথ্যা, নতুন সারি নেই, থামা। দ্বিতীয়টি ৬টি সারি, শেষ 32 — শর্ত নতুন মানের ওপর, তাই 64 তৈরিই হয় না। এই এক-ঘর-বেশি ভুল (off-by-one) recursive প্রশ্নে খুব প্রচলিত।

name              │ lvl
Tasnim Chowdhury  │ 0
Shahana Parvin    │ 1
Dr. Anisur Rahman │ 2

শুরুর সারি Tasnim (mentor 2). প্রথম ধাপে instructor 2 = Shahana (mentor 1), দ্বিতীয় ধাপে instructor 1 = Anisur (mentor NULL). তৃতীয় ধাপে i.instructor_id = NULL কারও সাথে মেলে না — নতুন সারি নেই, তাই থামে। NULL-ই এখানে থামার শর্ত। ডেটায় চক্র থাকলে (A-র mentor B, B-র mentor A) এই কোয়েরি থামত না — তখন recursive অংশে WHERE c.lvl < 10-এর মতো সীমা দিতে হয়। (এখানে UNION দিয়েও বাঁচা যেত না, কারণ lvl প্রতিবার বাড়ে বলে প্রতিটি সারিই নতুন।)

-- ফ-৩২: দুই রকম থামার শর্ত
WITH RECURSIVE n(i) AS (SELECT 1 UNION ALL SELECT i * 2 FROM n WHERE i < 50)
SELECT COUNT(*) AS rows_, MAX(i) AS last FROM n;
WITH RECURSIVE n(i) AS (SELECT 1 UNION ALL SELECT i * 2 FROM n WHERE i * 2 < 50)
SELECT COUNT(*) AS rows_, MAX(i) AS last FROM n;

-- ফ-৩৩: Tasnim থেকে ওপরের দিকে
WITH RECURSIVE chain(id, name, mentor_id, lvl) AS (
  SELECT instructor_id, name, mentor_id, 0
  FROM instructors WHERE instructor_id = 6
  UNION ALL
  SELECT i.instructor_id, i.name, i.mentor_id, c.lvl + 1
  FROM instructors i JOIN chain c ON i.instructor_id = c.mentor_id)
SELECT name, lvl FROM chain;

শুধু Dilruba Khatun. কোয়েরিটি পড়ুন এভাবে: “এমন কোনো কোর্স নেই, যেটিতে শিক্ষার্থীটি ভর্তি হননি।” Arif-এর CSE101 নেই, Bristy-র CSE101 নেই, Gulshan-এর CSE201 নেই। Dilruba-র তিনটিই আছে — grade NULL হলেও ভর্তির সারিটি আছে, আর কোয়েরি grade দেখে না। “পাস করেছেন” চাইলে ভেতরে AND e.grade IS NOT NULL AND e.grade <> 'F' লাগত, তখন Dilruba-ও বাদ।

dept_id = 99 হলে ৮ জনই আসেন। কোর্সের সেট খালি হলে “এমন কোনো কোর্স নেই যেটি তিনি নেননি” সবার জন্য সত্য — গণিতের ভাষায় vacuous truth. Division-এর এই আচরণ বীজগণিতের সংজ্ঞার সাথেও মেলে, কিন্তু রিপোর্টে প্রায়ই অপ্রত্যাশিত।

name  │ salary │ rn │ rk │ dr
Rina  │ 50000  │ 1  │ 1  │ 1
Babu  │ 50000  │ 2  │ 1  │ 1
Sumon │ 40000  │ 3  │ 3  │ 2
Tania │ 40000  │ 4  │ 3  │ 2
Kamal │ 30000  │ 5  │ 5  │ 3
Lipi  │ NULL   │ 6  │ 6  │ 4

ROW_NUMBER সবসময় আলাদা নম্বর (টাই id দিয়ে ভাঙা)। RANK = আমার চেয়ে আগের সারির সংখ্যা + 1, তাই টাই-এর পরে ফাঁক (1, 1, 3). DENSE_RANK = আগের আলাদা মানের সংখ্যা + 1, ফাঁক নেই। Lipi-র NULL একটি আলাদা মান হিসেবেই র‍্যাংক পায় — SQLite-এ DESC ক্রমে শেষে। PostgreSQL-এ DESC-এ NULL প্রথমে, সেখানে Lipi হতেন rn 1, rk 1, dr 1, আর বাকি সবার নম্বর এক ঘর করে সরে যেত।

name  │ dept │ salary
Sumon │ CSE  │ 40000
Lipi  │ EEE  │ NULL

CSE: 50000 (Rina, Babu) dr 1, 40000 (Sumon) dr 2 — ঠিক। NULL দলে শুধু Kamal, dr 2 কেউ নেই। চমকটি EEE-তে: Tania 40000 dr 1, আর Lipi-র NULL একটি আলাদা মান হিসেবে dr 2 পায়! “বেতন জানা নেই” এমন কাউকে “দ্বিতীয় সর্বোচ্চ বেতন” বলা অর্থহীন। PostgreSQL-এ DESC-এ NULL প্রথমে: Lipi dr 1, Tania dr 2 — ফল Sumon আর Tania. দুই DBMS-এ দুই রকম, দুটিই প্রশ্নের দিক থেকে ভুলের ঝুঁকিতে। ঠিক পথ: CTE-র ভেতরে WHERE salary IS NOT NULL.

-- ফ-৩৫: তিন রকম র‍্যাংক
SELECT name, salary,
       ROW_NUMBER() OVER (ORDER BY salary DESC, id) AS rn,
       RANK()       OVER (ORDER BY salary DESC)     AS rk,
       DENSE_RANK() OVER (ORDER BY salary DESC)     AS dr
FROM emp ORDER BY rn;

-- ফ-৩৬: NULL বাদ দিয়ে দ্বিতীয় সর্বোচ্চ
WITH r AS (
  SELECT name, dept, salary,
         DENSE_RANK() OVER (PARTITION BY dept ORDER BY salary DESC) AS dr
  FROM emp WHERE salary IS NOT NULL)
SELECT name, dept, salary FROM r WHERE dr = 2 ORDER BY dept;

name  │ salary │ s_range │ s_rows
Lipi  │ NULL   │ NULL    │ NULL
Kamal │ 30000  │ 30000   │ 30000
Sumon │ 40000  │ 110000  │ 70000
Tania │ 40000  │ 110000  │ 110000
Rina  │ 50000  │ 210000  │ 160000
Babu  │ 50000  │ 210000  │ 210000

ORDER BY দিলে default frame হলো RANGE … CURRENT ROW — বর্তমান সারির সব সমান-মানের সঙ্গী (peer)-সহ। তাই Sumon-এর সারিতেই Tania-র 40000 ঢুকে 110000. ROWS এক সারি করে এগোয়: 30000, 70000, 110000… Lipi প্রথম সারি (SQLite-এ ছোট থেকে বড়-তে NULL আগে), frame-এ শুধু NULL — SUM NULL. PostgreSQL-এ Lipi শেষে আসতেন, আর তাঁর s_range হতো 210000 (frame-এ সবাই, SUM NULL বাদ দেয়)।

id │ salary │ prev  │ diff
1  │ 50000  │ NULL  │ 50000
2  │ 40000  │ 50000 │ -10000
3  │ 40000  │ 40000 │ 0
4  │ 30000  │ 40000 │ -10000
5  │ NULL   │ 30000 │ NULL
6  │ 50000  │ NULL  │ NULL

id 1-এর আগে কোনো সারি নেই — prev NULL, কিন্তু LAG(…, 1, 0) default 0 দেয়, diff = 50000. id 5: নিজের বেতন NULL, তাই NULL − 30000 = NULL. id 6: আগের সারি আছে (Lipi), তার মান NULL — default শুধু “সারি নেই” হলে কাজ করে, “মান NULL” হলে নয়। তাই diff NULL. এই পার্থক্যটি পরীক্ষায় প্রায়ই ধরা হয়।

-- ফ-৩৭: RANGE বনাম ROWS
SELECT name, salary,
       SUM(salary) OVER (ORDER BY salary) AS s_range,
       SUM(salary) OVER (ORDER BY salary, id
                         ROWS UNBOUNDED PRECEDING) AS s_rows
FROM emp ORDER BY salary, id;

-- ফ-৩৮: LAG-এর default আর NULL
SELECT id, salary,
       LAG(salary) OVER (ORDER BY id) AS prev,
       salary - LAG(salary, 1, 0) OVER (ORDER BY id) AS diff
FROM emp ORDER BY id;

(১) Rina | 3. WHERE আগে চলে (৩ জন CSE), window সেই ৩ জনের ওপর হিসাব করে, LIMIT সবার শেষে একটি সারি রাখে — কিন্তু total-এ 3 থেকেই যায়, 1 নয়। (২) ৬টি সারি — window সারি গোটায় না; CSE-র তিনটি সারিতেই 46666.67… (৩) ৩টি সারি — DISTINCT চলে window-এর পরে, একই (dept, গড়) জোড়াগুলো এক করে। ফল GROUP BY-এর মতো দেখালেও কাজটি অনেক বেশি; সরাসরি GROUP BY লেখাই ভালো।

id 1, 2 → 1; id 3, 4 → 2; id 5 → 3; id 6 → 4. ৬ ÷ ৪ = ১, ভাগশেষ ২. প্রতিটি ভাগে অন্তত ১টি সারি, আর প্রথম ২টি (ভাগশেষের সমান) ভাগে একটি করে বেশি: আকার ২, ২, ১, ১. NTILE মান দেখে না, শুধু সারি গোনে — তাই সমান বেতনের দুজন আলাদা ভাগে যেতে পারেন।

প্রথমটিতে ২টি সারি, দ্বিতীয়টিতে ০টি। WHERE Tania আর Lipi দুজনকেই ধরে, তাই SQLite (আর বেশিরভাগ DBMS) বলে ২টি সারি বদলেছে — যদিও Lipi-র মান NULL + 5000 = NULL-ই থেকে গেছে। Tania এখন 45000. দ্বিতীয়টিতে = NULL কোনো সারি ধরে না (ফ-০৯), কোনো ত্রুটিও দেয় না। একটি পার্থক্য: MySQL ডিফল্টভাবে শুধু যে সারির মান সত্যিই বদলেছে সেগুলো “affected” বলে, তাই প্রথমটিতেও সেখানে ১ দেখাত।

SQLite, PostgreSQL, SQL Server, Oracle: a = 20, b = 10 — অদলবদল হয়। Standard SQL-এ SET-এর ডান দিকের সব expression হিসাব হয় সারির পুরোনো মান দিয়ে, যেন সব একসাথে বসানো হলো। MySQL-এ a = 20, b = 20. MySQL একক টেবিলের UPDATE-এ বাঁ থেকে ডানে একটি একটি করে বসায়, তাই b = a দেখে নতুন a (20). MySQL-এর documentation নিজেই এই আচরণ উল্লেখ করে — মান অদলবদলে সেখানে একটি অস্থায়ী মান লাগে।

৩টি সারি মোছে (Sumon, Tania, Kamal); থাকেন Rina, Lipi, Babu. গড় একবারই হিসাব হয় — মোছার আগের টেবিলে, 42000. প্রতিটি মোছার পরে নতুন গড় হলে ফল সারির ক্রমের ওপর নির্ভর করত, যা SQL-এর অর্থের সাথে মেলে না। Lipi টিকে যান: NULL < 42000 UNKNOWN, আর DELETE-ও শুধু TRUE সারি মোছে। (MySQL-এ একই টেবিল subquery-তে পড়ে DELETE করা যায় না — ত্রুটি 1093; subquery-কে আরেকটি derived table-এ মুড়ে লিখতে হয়।)

-- ফ-৪১
UPDATE emp SET salary = salary + 5000 WHERE dept = 'EEE';
UPDATE emp SET dept = 'BBA' WHERE dept = NULL;

-- ফ-৪২
UPDATE p SET a = b, b = a;
SELECT * FROM p;

-- ফ-৪৩ (খেয়াল করুন: ফ-৪১-এর পরে Tania এখন 45000)
DELETE FROM emp WHERE salary < (SELECT AVG(salary) FROM emp);
SELECT name, salary FROM emp ORDER BY id;

ত্রুটি (UNIQUE constraint failed: t.id), আর t-তে ১টি সারিই থাকে। (2, 'b') আগে ঢুকেছিল, কিন্তু স্টেটমেন্ট ব্যর্থ হওয়ায় সেটিও ফিরিয়ে নেওয়া হয় — statement atomicity. “প্রথম সারি ঢুকে গেছে” ভাবা সাধারণ ভুল। INSERT OR IGNORE (SQLite; MySQL-এ INSERT IGNORE, PostgreSQL-এ ON CONFLICT DO NOTHING) সমস্যার সারিটি বাদ দিয়ে বাকিগুলো রাখে: (1, 'a'), (2, 'b'), (3, 'd') — ৩টি সারি, আর বার্তা “২টি সারি বদলেছে”।

প্রথম দুটি সফল, তৃতীয়টি ব্যর্থ (CHECK constraint failed). CHECK শুধু FALSE হলে আটকায়; NULL BETWEEN 0 AND 4 UNKNOWN, তাই NULL cgpa ঢুকে যায়। NULL আটকাতে আলাদা NOT NULL লাগে। UNIQUE-এর চোখে দুটি NULL “সমান” নয়, তাই দ্বিতীয় NULL phone-ও বৈধ — SQLite, PostgreSQL, MySQL আর Oracle-এ। SQL Server এখানে ব্যতিক্রম: UNIQUE constraint সেখানে একটির বেশি NULL মানে না। (PostgreSQL 15 থেকে চাইলে UNIQUE NULLS NOT DISTINCT লিখে SQL Server-এর মতো আচরণ পাওয়া যায়।)

প্রথমটি সফল (১টি সারি), দ্বিতীয়টি ব্যর্থ — FOREIGN KEY constraint failed. Rahim-কে মুছলে তিনটি অর্ডার এমন গ্রাহককে নির্দেশ করত, যিনি নেই। ON DELETE না লিখলে ডিফল্ট NO ACTION — মোছা আটকায়। মনে রাখুন, SQLite-এ foreign key তখনই কাজ করে, যখন PRAGMA foreign_keys = ON (এই পাতার এডিটরে চালু); ডিফল্টভাবে বন্ধ থাকে, তখন দ্বিতীয় DELETE-ও নিঃশব্দে সফল হতো।

-- ফ-৪৫: CHECK আর UNIQUE-এ NULL
INSERT INTO students VALUES (2401, 'Jui Akter', 1, 2024, NULL);
INSERT INTO customers VALUES (9, 'Nayeem Islam', 'Barishal', NULL, '2025-09-30');
SELECT COUNT(*) AS null_phones FROM customers WHERE phone IS NULL;

-- ফ-৪৬: FOREIGN KEY
DELETE FROM customers WHERE customer_id = 5;
DELETE FROM customers WHERE customer_id = 1;   -- এখানে ত্রুটি

changes() = 1, child-এ ১টি সারি। CASCADE তিনটি child সারিও মুছেছে, কিন্তু SQLite-এর changes() শুধু স্টেটমেন্টটি সরাসরি যে টেবিলে কাজ করেছে, সেখানকার সারি গোনে — foreign key action বা trigger-এ বদলানো সারি নয়। তাই “কয়টি সারি গেল” জানতে child টেবিলেই গুনুন। অ্যাপের লগে “১টি সারি মুছেছে” দেখে ভরসা করা বিপজ্জনক হতে পারে।

প্রথম INSERT সফল, Headphone-এর stock 37. দ্বিতীয়টি ব্যর্থ — CHECK constraint failed: stock >= 0; Power Bank-এর stock 0-ই থাকে, আর order_items-এ নতুন সারিটিও নেই। Trigger-এর কাজ স্টেটমেন্টেরই অংশ: trigger-এর ভেতরের UPDATE ব্যর্থ হলে পুরো INSERT ফিরিয়ে নেওয়া হয়। এভাবেই “স্টকের বেশি বিক্রি” ডেটাবেস নিজেই আটকায়।

id │ bal
1  │ 800
2  │ 800

SAVEPOINT-এর আগের কাজ (id 1 থেকে 200 কমানো) টিকে থাকে। ROLLBACK TO s1 শুধু s1-এর পরের দুটি UPDATE বাতিল করে — id 2-এর +200 আর id 1-এর 0. Transaction তখনও খোলা; তারপর id 2-এ +300, আর COMMIT সব স্থায়ী করে: 1000 − 200 = 800, 500 + 300 = 800. সাধারণ ভুল: ROLLBACK TO-কে পুরো transaction-এর ROLLBACK ভাবা (তাহলে 1000 আর 800 হতো না), অথবা ভাবা যে এর পরে transaction শেষ।

BEGIN;
UPDATE acc SET bal = bal - 200 WHERE id = 1;
SAVEPOINT s1;
UPDATE acc SET bal = bal + 200 WHERE id = 2;
UPDATE acc SET bal = 0 WHERE id = 1;
ROLLBACK TO s1;
UPDATE acc SET bal = bal + 300 WHERE id = 2;
COMMIT;
SELECT * FROM acc;

-- আরেকটি: RELEASE কি COMMIT?
BEGIN;
DELETE FROM acc WHERE id = 2;
SAVEPOINT a;
UPDATE acc SET bal = 1 WHERE id = 1;
RELEASE a;
ROLLBACK;
SELECT * FROM acc;

SQLite: (1, 'a'), (2, 'b'), (3, 'c'). ব্যর্থ স্টেটমেন্টটি একাই ফিরিয়ে নেওয়া হয়; transaction খোলা থাকে, পরের INSERT চলে, COMMIT বাকিগুলো স্থায়ী করে। MySQL (InnoDB) আর SQL Server-এর ডিফল্ট আচরণও এ রকম — অ্যাপকেই ত্রুটি দেখে ROLLBACK করতে হয়। PostgreSQL: শুধু (1, 'a'). সেখানে একটি ত্রুটির পরে পুরো transaction “aborted” অবস্থায় যায়: পরের INSERT বাতিল হয় (current transaction is aborted…), আর COMMIT আসলে ROLLBACK করে। একই কোড, দুই DBMS-এ দুই ফল — তাই অ্যাপে ত্রুটি ধরলেই নিজে ROLLBACK করাই নিরাপদ অভ্যাস (পর্ব ৪৪, ৪৯)। (এই প্রশ্নের জন্য লাইভ এডিটর নেই, কারণ এডিটর প্রথম ত্রুটিতেই থেমে যায়; উত্তরটি Python-এর sqlite3 দিয়ে চালিয়ে যাচাই করা।)