SELECT — বাছাই, ফিল্টার আর সাজানো

১ · SELECT-এর গঠন — একটি প্রশ্নের ব্যাকরণ

আগের পর্বগুলোতে টেবিল বানিয়েছেন (পর্ব ১৩) আর ডেটা ঢুকিয়েছেন-বদলেছেন (পর্ব ১৪)। এবার আসল কাজ — ডেটা থেকে প্রশ্নের উত্তর বের করা। SQL-এ প্রায় সব প্রশ্ন শুরু হয় একটি শব্দে: SELECT.

একটি পূর্ণ SELECT-এর কাঠামো এমন (বর্গবন্ধনীর অংশগুলো ঐচ্ছিক; GROUP BY আর HAVING আসবে পর্ব ১৮-তে):

SELECT [DISTINCT] কলাম বা হিসাব [AS নাম], ...
FROM   টেবিল
[WHERE    সারি বাছাইয়ের শর্ত]
[ORDER BY কলাম [ASC | DESC], ...]
[LIMIT    কয়টি সারি [OFFSET কয়টি বাদ]];

প্রতিটি অংশকে বলে একটি clause. কোয়েরির ফল সবসময় আরেকটি টেবিল — একে বলে result set. তাই একটি কোয়েরির ফল আরেকটি কোয়েরির ইনপুট হতে পারে (পর্ব ২১-এর subquery-তে দেখবেন)।

এই পর্বের বেশিরভাগ উদাহরণ চলবে দোকানের নমুনা ডেটাবেস db-shop-এ। মূল টেবিল দুটি: products — product_id, name, category_id (1 = Electronics, 2 = Books, 3 = Clothing, 4 = Grocery), price (টাকা) আর stock (গুদামে কয়টি আছে); আর customers — customer_id, name, city, phone আর joined_on (যোগ দেওয়ার তারিখ, 'YYYY-MM-DD' লেখা হিসেবে)। orders টেবিলে আছে order_id, customer_id, order_date আর status. এডিটরের নিচের “নমুনা ডেটাবেস” বাক্স খুললে পুরো ডেটা দেখতে পাবেন।

-- সব কলাম, সব সারি
SELECT * FROM categories;

-- শুধু দুটি কলাম
SELECT name, price FROM products;

-- FROM ছাড়াও SELECT চলে: একটি হিসাব
SELECT 2 + 3 AS answer;

২ · Alias আর হিসাব করা কলাম

SELECT-এর তালিকায় শুধু কলামের নাম নয়, যেকোনো হিসাব (expression) লেখা যায় — যেমন price * stock, মানে গুদামের মালের মোট মূল্য। এমন কলামকে বলে computed column. এর একটি পড়ার মতো নাম দিতে লেখা হয় AS নাম — একে বলে column alias.

-- গুদামে প্রতিটি পণ্যের মোট মূল্য
SELECT name AS product, price, stock,
       price * stock AS stock_value
FROM products;

-- ফাঁকা জায়গা বা বাংলা নাম: ডাবল কোটে
SELECT name AS "পণ্যের নাম", price * stock AS "stock value"
FROM products;

-- কমা ভুলে গেলে?
SELECT name price FROM products;

হিসাব করা কলামে দুটি ছোট ফাঁদ মনে রাখুন। প্রথমত, দুটি পূর্ণসংখ্যার ভাগে SQLite আর PostgreSQL ভাগফলের দশমিক অংশ ফেলে দেয়: SELECT 7 / 2 দেয় 3, 3.5 নয়। দশমিক চাইলে একটিকে দশমিক সংখ্যা করুন: 7 / 2.0. MySQL-এ আবার 7 / 2 দেয় 3.5000, আর পূর্ণসংখ্যার ভাগের জন্য আলাদা অপারেটর DIV. দ্বিতীয়ত, হিসাবের যেকোনো অংশ NULL হলে পুরো ফলই NULL: দাম জানা না থাকলে price * stock-ও অজানা। db-shop-এ price আর stock দুটোই NOT NULL, তাই এখানে সমস্যা নেই — কিন্তু বাস্তব টেবিলে সবসময় দেখে নিন।

৩ · DISTINCT — একই সারি একবার

পর্ব ০৫-এ দেখেছেন, SQL-এর ফল আসলে bag — একই সারি একাধিকবার থাকতে পারে। “আমাদের গ্রাহকেরা কোন কোন শহরের?” প্রশ্নে ঢাকা তিনবার দেখতে চান না। DISTINCT লিখলে ফলের প্রতিটি সারি একবারই আসে।

SELECT city FROM customers;            -- ৮টি সারি
SELECT DISTINCT city FROM customers;   -- আলাদা শহর

-- কয়েকটি কলামে: আলাদা জোড়া
SELECT DISTINCT customer_id, status FROM orders;

৪ · WHERE — শর্ত দিয়ে সারি ছাঁকা

SELECT কলাম বাছে; WHERE বাছে সারি। WHERE-এর শর্ত প্রতিটি সারির জন্য আলাদা করে যাচাই হয়; যে সারিতে ফল TRUE, শুধু সেটি থাকে। শর্ত লেখার মূল হাতিয়ার comparison operator:

<> হলো স্ট্যান্ডার্ড; != প্রায় সব ডেটাবেসে চলে। SQLite-এ ==-ও চলে, কিন্তু অন্য কোথাও নয় — অভ্যাস করবেন না। BETWEEN, IN, LIKE-এর পূর্ণ আলোচনা আর NULL-এর সঙ্গে তুলনা আসছে পর্ব ১৬-তে। এখন সংখ্যা আর তারিখ দিয়ে ছাঁকি:

-- হাজার টাকার কম দামের পণ্য, সস্তা থেকে দামি
SELECT name, price FROM products
WHERE price < 1000
ORDER BY price;

-- কোন পণ্য গুদামে শেষ?
SELECT name, stock FROM products WHERE stock = 0;

-- অক্টোবর ২০২৫ বা তার পরের অর্ডার
SELECT order_id, order_date, status FROM orders
WHERE order_date >= '2025-10-01';

লেখার তুলনা: বড় হাতের অক্ষর আর ছোট হাতের অক্ষর

লেখা (string) তুলনার নিয়ম ঠিক করে collation — অক্ষর সাজানো আর মেলানোর নিয়মের একটি সেট। এখানেই ডেটাবেসগুলো সবচেয়ে বেশি আলাদা:

-- ঢাকার গ্রাহক, যোগ দেওয়ার তারিখের ক্রমে
SELECT name, joined_on FROM customers
WHERE city = 'Dhaka'
ORDER BY joined_on;

SELECT name FROM customers WHERE city = 'dhaka';      -- ছোট হাতের d
SELECT name FROM customers WHERE city LIKE 'dhaka';   -- LIKE দিয়ে
SELECT name FROM customers WHERE city = 'dhaka' COLLATE NOCASE;

অর্থাৎ একই কোয়েরি MySQL-এ ৩ জন আর PostgreSQL-এ ০ জন দিতে পারে। একটি কোয়েরি এক ডেটাবেস থেকে আরেকটিতে নিলে লেখার তুলনাগুলো আবার যাচাই করুন। ব্যবহারকারীর লেখা খোঁজার সময় সাধারণত দুই দিকেই একই রূপ করে নেওয়া হয়, যেমন LOWER(city) = LOWER(?) (পর্ব ১৭)।

Collation শুধু = নয়, <, > আর ORDER BY-কেও নিয়ন্ত্রণ করে। SQLite-এর BINARY collation অক্ষর তুলনা করে তাদের কোড নম্বর দিয়ে, আর ASCII-তে সব বড় হাতের অক্ষর (A–Z) ছোট হাতের অক্ষরের (a–z) আগে। তাই সেখানে 'Zebra' < 'apple' সত্য, আর নাম সাজালে “Zahid” আসবে “abir”-এর আগে। ডেটা ঢোকানোর সময় নামের বানান-রীতি এক রাখা (প্রথম অক্ষর বড়) এই ঝামেলা অনেকটা কমায়।

৫ · AND, OR, NOT — আর বন্ধনীর দাম

কয়েকটি শর্ত জুড়তে লাগে logical operator: AND (দুটোই সত্য হতে হবে), OR (অন্তত একটি সত্য), NOT (উল্টে দেয়)। গণিতে যেমন গুণ আগে, যোগ পরে, SQL-এও তেমনি একটি operator precedence আছে: আগে তুলনা (=, < …), তারপর NOT, তারপর AND, সবশেষে OR.

ধরুন মালিক চান: “Electronics বা Books-এর পণ্য, যাদের দাম হাজার টাকার কম।” স্বাভাবিক ভাষা থেকে সরাসরি লিখলে যা হয়, ধাপে ধাপে দেখুন:

এবার নিজে চালিয়ে দুটি ফল মিলিয়ে নিন:

-- ফাঁদ: বন্ধনী নেই
SELECT product_id, name, category_id, price FROM products
WHERE category_id = 1 OR category_id = 2 AND price < 1000;

-- ঠিক: বন্ধনী দিয়ে অর্থ স্পষ্ট
SELECT product_id, name, category_id, price FROM products
WHERE (category_id = 1 OR category_id = 2) AND price < 1000;

-- NOT: ঢাকার বাইরের গ্রাহক
SELECT name, city FROM customers WHERE NOT city = 'Dhaka';

৬ · ORDER BY — সাজানো, আর সমান মানের সমস্যা

পর্ব ০৫-এ দেখেছেন, relation-এ সারির কোনো ক্রম নেই। তাই ক্রম চাইলে বলতে হয় ORDER BY দিয়ে। ASC মানে ছোট থেকে বড় (ডিফল্ট), DESC মানে বড় থেকে ছোট। একাধিক key দিলে প্রথমটি দিয়ে সাজানো হয়; প্রথমটিতে সমান হলে দ্বিতীয়টি দিয়ে, এভাবে — ঠিক অভিধানে শব্দ সাজানোর মতো।

এবার বিশ্ববিদ্যালয়ের নমুনা ডেটাবেস db-uni-র students টেবিল: student_id, name, dept_id, batch (ভর্তির বছর) আর cgpa (Fahim Karim-এর cgpa এখনো NULL).

-- CGPA 3.5 বা বেশি: সবচেয়ে বেশি থেকে
SELECT name, batch, cgpa FROM students
WHERE cgpa >= 3.5
ORDER BY cgpa DESC;

-- আগে নতুন ব্যাচ, প্রতিটি ব্যাচের ভেতরে বেশি CGPA আগে
SELECT name, batch, cgpa FROM students
ORDER BY batch DESC, cgpa DESC;

NULL কোথায় যাবে — ডেটাবেস ভেদে আলাদা

NULL কোনো সংখ্যা নয়, তাই “NULL ছোট না বড়” প্রশ্নের কোনো গাণিতিক উত্তর নেই। SQL স্ট্যান্ডার্ড বিষয়টি প্রতিটি ডেটাবেসের ওপর ছেড়ে দিয়েছে, আর সঙ্গে দিয়েছে স্পষ্ট করে বলার উপায়: NULLS FIRST / NULLS LAST. SQLite-এ এটি এসেছে ৩.৩০ সংস্করণে (২০১৯)।

SELECT name, cgpa FROM students ORDER BY cgpa;              -- SQLite: NULL আগে
SELECT name, cgpa FROM students ORDER BY cgpa NULLS LAST;
SELECT name, cgpa FROM students ORDER BY cgpa DESC NULLS FIRST;

Alias আর অবস্থান দিয়ে সাজানো

ORDER BY-তে SELECT-এর alias ব্যবহার করা যায়: ORDER BY stock_value DESC. কলামের অবস্থান দিয়েও লেখা যায়: SELECT name, price FROM products ORDER BY 2 DESC — “দ্বিতীয় কলাম দিয়ে সাজাও”। এটি ছোট, কিন্তু ভঙ্গুর: কেউ পরে SELECT-এ নতুন কলাম ঢোকালে 2 চুপচাপ অন্য কলাম বোঝাবে, কোনো error ছাড়া। SQL-92 স্ট্যান্ডার্ডে এই রীতিকে পুরোনো (deprecated) ঘোষণা করা হয়েছিল, পরে স্ট্যান্ডার্ড থেকে বাদও দেওয়া হয় — যদিও প্রায় সব ডেটাবেস এখনো মানে। দ্রুত খোঁজার সময় চলে; স্থায়ী কোডে নাম লিখুন।

ORDER BY-তে শুধু কলাম নয়, যেকোনো হিসাবও দেওয়া যায় — যেমন ORDER BY price * stock DESC, যা SELECT তালিকায় না থাকলেও চলে। আর একেক key-এর দিক আলাদা হতে পারে: ORDER BY batch DESC, name ASC. খেয়াল রাখবেন, DESC শুধু তার ঠিক আগের key-তে খাটে; ORDER BY batch, cgpa DESC-এ batch ছোট থেকে বড়ই থাকে।

৭ · LIMIT, OFFSET আর pagination

ই-কমার্স সাইটে হাজার পণ্য একসাথে দেখানো হয় না; দেখানো হয় পাতায় পাতায় — একে বলে pagination. SQLite, MySQL আর PostgreSQL-এ LIMIT n বলে “সর্বোচ্চ n-টি সারি”, আর OFFSET k বলে “তার আগে প্রথম k-টি বাদ দাও”। প্রতি পাতায় n-টি হলে পাতা p-এর জন্য OFFSET = (p − ১) × n.

-- সবচেয়ে দামি ৩টি পণ্য
SELECT name, price FROM products ORDER BY price DESC LIMIT 3;

-- পাতা ২ (প্রতি পাতায় ৪টি): প্রথম ৪টি বাদ
SELECT product_id, name, price FROM products
ORDER BY price, product_id
LIMIT 4 OFFSET 4;

-- একই পাতা, keyset পদ্ধতিতে: পাতা ১-এর শেষ সারি ছিল (650, 104)
SELECT product_id, name, price FROM products
WHERE price > 650 OR (price = 650 AND product_id > 104)
ORDER BY price, product_id
LIMIT 4;

খরচের হিসাবটি নিখুঁত করে বলি। N-টি সারি, প্রতি পাতায় n-টি, আর (price, product_id)-এ B+ tree index আছে। OFFSET k দিয়ে পাতা আনতে index-এর শুরু থেকে k + n-টি entry পার হতে হয় — খরচ Θ(k + n), কারণ সাধারণ B+ tree জানে না কোন entry ঠিক কততম; গুনতে হলে হাঁটতে হয়। Keyset-এ প্রথমে গাছের মূল থেকে পাতা পর্যন্ত একবার নামা — গাছের উচ্চতা h ≈ log_F N (F = প্রতিটি node-এ কয়টি শাখা, সাধারণত কয়েকশো), তাই বাস্তবে ৩–৪টি page — তারপর n-টি entry: খরচ O(log N + n). Index না থাকলে দুই পদ্ধতিতেই সব সারি পড়ে সাজাতে হয়, তাই keyset-এর সুবিধা পেতে index লাগবেই। Keyset-এর সীমাবদ্ধতা: “সরাসরি ৫৭ নম্বর পাতায় যাও” করা যায় না, আর sort key-কে অনন্য হতে হয়।

পুরো তালিকা পাতায় পাতায় পড়লে পার্থক্য আরও স্পষ্ট হয় — যেমন একটি রাতের ব্যাচ-জব, যা সব পণ্য ২০টি করে প্রসেস করে। মোট N = P × n সারি, P-টি পাতা। OFFSET-এ পাতা p-এর খরচ প্রায় p × n, তাই মোট n × (১ + ২ + … + P) = n × P(P + ১)/২ ≈ N²/(২n). Keyset-এ প্রতিটি পাতা log N + n, মোট প্রায় N + P log N. দশ লাখ সারি আর n = ২০ হলে OFFSET-এ মোট প্রায় ২,৫০০ কোটি entry পার হতে হয়, keyset-এ ১০ লাখের সামান্য বেশি। প্রথমটি বর্গের হারে বাড়ে, দ্বিতীয়টি প্রায় সরলরেখায়।

LIMIT সব ডেটাবেসে একই রকম লেখা হয় না। SQL:2008 স্ট্যান্ডার্ডের রূপ FETCH FIRST; এগুলো এই পাতায় চলবে না, শুধু চিনে রাখুন:

-- সবচেয়ে দামি ৩টি
SELECT name, price FROM products
ORDER BY price DESC
FETCH FIRST 3 ROWS ONLY;

-- পাতা ২ (প্রতি পাতায় ৪টি)
SELECT product_id, name, price FROM products
ORDER BY price, product_id
OFFSET 4 ROWS FETCH NEXT 4 ROWS ONLY;

-- পুরোনো রীতি: TOP
SELECT TOP 3 name, price FROM products
ORDER BY price DESC;

-- পাতা ২: SQL Server 2012 থেকে OFFSET ... FETCH (ORDER BY বাধ্যতামূলক)
SELECT product_id, name, price FROM products
ORDER BY price, product_id
OFFSET 4 ROWS FETCH NEXT 4 ROWS ONLY;

-- LIMIT n OFFSET k চলে; পুরোনো সংক্ষিপ্ত রূপ LIMIT k, n
SELECT product_id, name, price FROM products
ORDER BY price, product_id
LIMIT 4, 4;      -- আগে offset, পরে সংখ্যা!

MySQL-এর LIMIT 4, 4-এ প্রথম সংখ্যাটি offset — উল্টো পড়ে ভুল করা খুব সাধারণ। স্ট্যান্ডার্ডে একটি সুন্দর বাড়তি সুবিধাও আছে: FETCH FIRST 3 ROWS WITH TIES — তৃতীয় সারির সমান মানের সব সারিও ফলে রাখে (PostgreSQL ১৩ থেকে, Oracle 12c থেকে; SQL Server-এ TOP 3 WITH TIES).

৮ · লজিক্যাল প্রসেসিং ক্রম — SQL আসলে কোন ক্রমে ভাবে

আমরা লিখি SELECT দিয়ে শুরু করে। কিন্তু অর্থের দিক থেকে কোয়েরিটি চলে অন্য ক্রমে। একে বলে logical processing order:

প্রতিটি ধাপ আগের ধাপের ফল-টেবিল হাতে পায়, আর নিজের ফল দেয় পরের ধাপকে। একটি বাস্তব কোয়েরিতে প্রতিটি ধাপের পর কয়টি সারি থাকে, দেখুন — প্রশ্নটি: “২০০০ টাকার কম দামের পণ্য আছে এমন category, বড় নম্বর থেকে, প্রথম দুটি।”

এই ক্রম থেকেই একটি পরিচিত নিয়মের ব্যাখ্যা মেলে: SELECT-এর alias ORDER BY-তে চলে, কিন্তু WHERE-এ চলে না — কারণ WHERE চলার সময় alias জন্মায়ইনি। এখানে SQLite একটু ব্যতিক্রম; নিজে চালিয়ে দেখুন:

-- ১) ডায়াগ্রামের কোয়েরি
SELECT DISTINCT category_id AS cat FROM products
WHERE price < 2000 ORDER BY cat DESC LIMIT 2;

-- ২) ORDER BY-তে alias: সব ডেটাবেসে চলে
SELECT name, price * stock AS stock_value FROM products
ORDER BY stock_value DESC LIMIT 3;

-- ৩) WHERE-এ alias: SQLite চালায়, স্ট্যান্ডার্ড SQL-এ error
SELECT name, price * stock AS stock_value FROM products
WHERE stock_value > 40000;

-- ৪) একই SELECT-এ এক alias দিয়ে আরেকটি হিসাব: সবখানে error
SELECT name, price * stock AS stock_value,
       stock_value / 1000 AS thousands FROM products;

SELECT name, price * stock AS stock_value FROM products
WHERE stock_value > 40000;
-- ERROR:  column "stock_value" does not exist

-- ঠিক উপায়: WHERE-এ হিসাবটি নিজেই লিখুন
SELECT name, price * stock AS stock_value FROM products
WHERE price * stock > 40000;

মনে রাখবেন, এটি লজিক্যাল ক্রম — ফলটি কী হবে তার সংজ্ঞা। ভেতরে query optimizer ফল না বদলে কাজের ক্রম বদলাতে পারে — যেমন ORDER BY-এর সাথে মেলে এমন index থাকলে আলাদা sort না করে সরাসরি সাজানো ক্রমে পড়া, আর LIMIT পূর্ণ হলেই থেমে যাওয়া (পর্ব ৪৩)।

একটি SELECT লেখার অভ্যাস — লজিক্যাল ক্রম ধরে

1. প্রশ্নটি এক বাক্যে লিখুন — “২০০০ টাকার কম দামের পণ্য আছে এমন category, বড় নম্বর থেকে, প্রথম দুটি।”
2. FROM: উত্তর কোন টেবিলে আছে? WHERE: কোন সারিগুলো লাগবে? এখানে আগে SELECT COUNT(*) চালিয়ে দেখুন কয়টি সারি টিকছে।
3. SELECT: কোন কলাম আর হিসাব দেখাবেন, কী নামে? duplicate আসতে পারে কি না ভেবে DISTINCT ঠিক করুন।
4. ORDER BY: কোন ক্রমে, আর শেষে অনন্য tiebreaker আছে কি না। LIMIT: সবশেষে।
5. যাচাই: নমুনা ডেটায় হাতে দু-একটি সারি মিলিয়ে নিন — বিশেষ করে NULL আর সীমানার মান (ঠিক ২০০০ টাকার পণ্য কি থাকবে? < না <=?)।

৯ · AI-এর যুগে SELECT

“হাজার টাকার কম দামের বই বা ইলেকট্রনিক্স দেখাও” — AI এক সেকেন্ডে কোয়েরি লিখে দেবে, আর সেটা চলবেও। কিন্তু এই পর্বের প্রতিটি ফাঁদ — বন্ধনী, NULL-এর ক্রম, tiebreaker, লেখার বড়-ছোট অক্ষর, ডেটাবেস ভেদে আলাদা আচরণ — ঠিক সেই জায়গা, যেখানে AI-এর কোয়েরি চলে কিন্তু ভুল ফল দেয়।

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

• প্রতিটি টেবিল আর কলামের নাম আসল schema-র সঙ্গে মিলিয়েছি
• AND আর OR একসাথে থাকলে বন্ধনী আছে, আর বন্ধনীর অর্থ প্রশ্নের সঙ্গে মেলে
• LIMIT বা pagination থাকলে ORDER BY আছে, আর তার শেষে একটি অনন্য tiebreaker
• NULL থাকতে পারে এমন কলামে শর্ত বা সাজানোয় NULL-এর সারি কোথায় যাচ্ছে, দেখেছি
• নমুনা ডেটায় চালিয়ে সারির সংখ্যা হাতে গোনা সংখ্যার সঙ্গে মিলিয়েছি, আর লেখার তুলনা আমার ডেটাবেসের collation-এ ঠিক আছে
• বড় টেবিলে EXPLAIN দেখে নিশ্চিত হয়েছি যে ORDER BY-র জন্য পুরো টেবিল sort হচ্ছে না (পর্ব ৪১)