SQL ফাংশন — string, number আর date

১ · ফাংশন কী — scalar বনাম aggregate

পর্ব ১৫-এ SELECT দিয়ে কলাম বেছেছেন, পর্ব ১৬-এ অপারেটর আর CASE দিয়ে নতুন মান বানিয়েছেন। কিন্তু বাস্তবের প্রশ্নগুলো প্রায়ই এমন: “নামগুলো বড় হাতের অক্ষরে দেখাও”, “ফোন নম্বরের শেষ ছয় অঙ্ক লুকাও”, “VAT-সহ দাম দুই দশমিক ঘরে”, “কোন মাসে কয়টি অর্ডার?” এসব কাজের জন্য SQL-এ তৈরি থাকে অনেক ফাংশন — নাম, তারপর বন্ধনীর ভেতরে এক বা একাধিক মান (argument), আর ফেরত আসে একটি মান।

এই পর্বের সব ফাংশন scalar: প্রতিটি সারির জন্য একবার চলে, সেই সারির মান নিয়ে একটি ফল দেয়, আর সারির সংখ্যা বদলায় না। Aggregate ফাংশন (COUNT, SUM, AVG, MIN, MAX) সারিগুলোকে একটি দলে গুটিয়ে ফেলে — GROUP BY আর HAVING-সহ সেটি পরের পর্ব ১৮-এর বিষয়। নিচের এডিটরে দুই ধরনের পার্থক্য নিজের চোখে দেখুন। এডিটরটি পাতাতেই আসল SQLite চালায়: প্রতিবার “রান” চাপলে নতুন করে দোকানের নমুনা ডেটাবেস (db-shop) লোড হয়, তারপর আপনার কোড চলে। এখানে লাগবে products টেবিল — product_id, name (পণ্যের নাম), category_id, price (টাকা), stock (মজুত)।

-- scalar: প্রতিটি সারির জন্য একটি করে ফল
SELECT name, upper(name) AS big, length(name) AS letters
FROM products
WHERE product_id <= 103;

-- aggregate: অনেক সারি মিলে একটি ফল (পর্ব ১৮)
SELECT COUNT(*) AS products, MAX(price) AS costliest,
       MIN(length(name)) AS shortest_name
FROM products;

ফাংশনগুলোকে চার পরিবারে ভাগ করে মনে রাখা সহজ:

২ · লেখার দৈর্ঘ্য আর বড়-ছোট হাতের অক্ষর — বাংলা লেখায় সাবধান

String ফাংশন-এর প্রথম প্রশ্নটিই সবচেয়ে গভীর: একটি লেখা কত “লম্বা”? ইংরেজিতে উত্তর সহজ — 'Dhaka' পাঁচ অক্ষর, কম্পিউটারে পাঁচ বাইট। বাংলায় তিনটি আলাদা উত্তর আছে, আর DBMS-গুলো একেকটি বেছে নেয়।

• বাইট: ডিস্কে কত জায়গা লাগে। আজকের ডেটাবেস সাধারণত লেখা রাখে UTF-8 encoding-এ, যেখানে ইংরেজি অক্ষর ১ বাইট, কিন্তু প্রতিটি বাংলা অক্ষর ৩ বাইট।
• Code point: Unicode প্রতিটি অক্ষর-চিহ্নকে একটি নম্বর দেয় — ব = U+09AC, া (আ-কার) = U+09BE. এই নম্বরকে বলে code point. SQLite-এর length() এগুলোই গোনে।
• চোখে দেখা অক্ষর: পাঠক যাকে একটি অক্ষর ভাবেন — যেমন “ক্ষ” — সেটি আসলে ক + ্ (হসন্ত) + ষ, তিনটি code point. চোখে দেখা এই এককের নাম grapheme cluster; প্রায় কোনো DBMS-এর সাধারণ length এটি গোনে না।

SELECT length('বাংলা')       AS chars,
       octet_length('বাংলা') AS bytes,
       length('ক্ষ')          AS kkha,
       unicode('বাংলা')      AS first_code_point;

SELECT upper('dhaka') AS en, upper('ঢাকা') AS bn, upper('café') AS accent;

SELECT 'Dhaka' = 'dhaka' AS same, lower('Dhaka') = lower('dhaka') AS same_lower;

বাংলা নাম খুঁজতে বা সাজাতে এই পার্থক্যগুলো বাস্তব প্রভাব ফেলে। “রহিম” আর “রহীম” দুটি আলাদা বানান — কোনো ফাংশন এদের এক করবে না; একই শব্দ দুই ভাবে টাইপ করা (যেমন যুক্তাক্ষর ভিন্ন ক্রমে) হলেও লেখা দুটি বাইটে আলাদা হতে পারে। Unicode আর বাংলা টাইপিংয়ের ভেতরের গল্প পাবেন কম্পিউটার ফান্ডামেন্টালস কোর্সের বাংলা টাইপিং আর Unicode পর্বে।

৩ · লেখা কাটা, খোঁজা, বদলানো আর জোড়া

দৈনন্দিন কাজের বেশিরভাগই এই কয়েকটি ফাংশনে হয়। SQLite-এ লেখার অবস্থান গোনা শুরু হয় ১ থেকে, ০ থেকে নয় — প্রোগ্রামিং ভাষার সাথে এখানেই প্রথম গোলমাল হয়।

অন্য DBMS-এ নাম একটু আলাদা: substring(x FROM 1 FOR 6) হলো SQL standard-এর রূপ (PostgreSQL, MySQL দুটিতেই চলে; SQLite-এ substring(x, 1, 6) নামটিও চলে), আর instr-এর standard সমতুল্য position('Phone' IN 'Mobile Phone'). বাস্তবে ফাংশন একটির ভেতরে আরেকটি বসিয়ে কাজ হয়। ধরুন পণ্যের নামের প্রথম শব্দটি বড় হাতে চাই। DBMS কীভাবে একটি nested expression হিসাব করে, ভেতর থেকে বাইরে, ধাপে ধাপে দেখুন:

এবার আসল products টেবিলে। একই সাথে দেখুন পণ্যের নাম থেকে URL-এর অংশ (slug) বানানো আর রসিদের লাইনের মতো সমান প্রস্থে সাজানো:

SELECT name,
       instr(name, ' ')                      AS space_at,
       substr(name, 1, instr(name, ' ') - 1) AS first_word,
       lower(replace(name, ' ', '-'))        AS url_slug,
       printf('%-14s %9.2f', name, price)    AS bill_line
FROM products
WHERE product_id IN (101, 104, 107, 108);

ফোন নম্বর লুকানো — masking

কল সেন্টারের স্ক্রিনে বা রসিদে পুরো ফোন নম্বর দেখানোর দরকার নেই। customers টেবিলে (customer_id, name, city, phone, joined_on) প্রত্যেকের ফোন আছে, শুধু Tanvir Ahmed-এর phone NULL:

SELECT name, phone,
       substr(phone, 1, 5) || '******'                     AS masked,
       substr(phone, 1, 3) || '*****' || substr(phone, -3) AS masked_ends,
       coalesce(substr(phone, 1, 5) || '******', 'নম্বর নেই') AS safe_masked
FROM customers;

জোড়া লাগানো আর শূন্য দিয়ে ভরা — DBMS-ভেদে পার্থক্য

SQL standard-এ জোড়ার অপারেটর ||; SQLite, PostgreSQL আর Oracle এটি মানে। কিন্তু MySQL-এ ডিফল্টে || মানে যৌক্তিক OR, তাই সেখানে CONCAT() লিখতে হয় — আর MySQL-এর CONCAT-এ একটি argument NULL হলেই পুরো ফল NULL, যেখানে PostgreSQL আর SQLite-এর concat NULL বাদ দেয়। অর্ডার নম্বর ৭ থেকে '007' বানানোর জন্য PostgreSQL আর MySQL-এ LPAD আছে, SQLite-এ নেই; সেখানে দুটি বিকল্প: printf('%03d', 7) অথবা substr('000' || 7, -3) (সামনে শূন্য জুড়ে শেষ তিনটি নেওয়া) — দুটিই '007' দেয়।

SELECT lpad('7', 3, '0');                   -- '007'
SELECT format('%s-%s', 'INV', 1001);        -- 'INV-1001'
SELECT position('Phone' IN 'Mobile Phone'); -- 8
SELECT 'a' || NULL, concat('a', NULL, 'b'); -- NULL, 'ab'

SELECT LPAD('7', 3, '0');                       -- '007'
SELECT CONCAT('a', NULL, 'b');                  -- NULL (!)
SELECT CONCAT_WS('-', 'a', NULL, 'b');          -- 'a-b'
SELECT LENGTH('বাংলা'), CHAR_LENGTH('বাংলা');   -- 15, 5 (utf8mb4)

৪ · অগোছালো ডেটা পরিষ্কার — trim আর lower দিয়ে শুরু

অনলাইন ফর্মে শহরের নাম যে যেভাবে খুশি লেখেন: “ dhaka”, “DHAKA ”, “Dhaka”, “Ctg”, “chattogram”. মানুষের চোখে সব ঠিক আছে, কিন্তু DBMS-এর কাছে ' dhaka' আর 'Dhaka' দুটি আলাদা লেখা — GROUP BY করলে দুটি আলাদা দল, WHERE city = 'Dhaka' লিখলে একটি বাদ। এমন ডেটাকে নির্ভরযোগ্য করার কাজকে বলে data cleaning. নিচের সাতজন নতুন গ্রাহকের signup টেবিলে (id, name, city) ধাপে ধাপে পরিষ্কার করা দেখুন:

-- 1) আগে: একই শহর কত রূপে?
SELECT city, COUNT(*) AS n FROM signup GROUP BY city;

-- 2) পরিষ্কার করে দেখি, এখনো কিছু বদলাইনি
SELECT id, '[' || city || ']' AS raw,
       CASE lower(trim(city)) WHEN 'ctg' THEN 'chattogram'
            ELSE lower(trim(city)) END AS clean
FROM signup;

-- 3) নিশ্চিত হলে স্থায়ীভাবে বদলান, তারপর আবার গুনুন
UPDATE signup SET city = CASE lower(trim(city)) WHEN 'ctg' THEN 'chattogram'
                         ELSE lower(trim(city)) END;
UPDATE signup SET city = upper(substr(city, 1, 1)) || substr(city, 2);
SELECT city, COUNT(*) AS n FROM signup GROUP BY city ORDER BY n DESC, city;

৫ · সংখ্যার ফাংশন — রাউন্ড, ভাগ আর টাইপ বদল

ROUND আর VAT-এর হিসাব

round(x, n) x-কে n দশমিক ঘরে রাউন্ড করে; n না দিলে পূর্ণসংখ্যায়। দোকানের দামের সাথে ১৫% VAT যোগ করে দেখা যাক। ১৫% এখানে শুধু উদাহরণের হার — বাস্তবে VAT-এর হার পণ্য, সেবা আর সময়ের আইন অনুযায়ী আলাদা হতে পারে, তাই আসল সিস্টেমে হারটি একটি টেবিলে রাখুন, কোয়েরিতে লিখে দেবেন না।

-- 15% একটি উদাহরণ হার
SELECT name, price,
       price * 1.15           AS raw_total,
       round(price * 1.15, 2) AS with_vat,
       round(price * 1.15)    AS whole_taka
FROM products
WHERE product_id IN (101, 104, 105, 109);

SELECT 650 * 1.15 = 747.5 AS exact_equal,
       round(2.5) AS r1, round(-2.5) AS r2, round(2.675, 2) AS r3;

সমাধান পর্ব ১১-এর নিয়মটিই: টাকা রাখুন পয়সায়, পূর্ণসংখ্যায়। 650 টাকা = 65000 পয়সা; VAT-সহ = (65000 × 115 + 50) / 100 = 74750 পয়সা — পূর্ণসংখ্যার যোগ-গুণ-ভাগ সবসময় নিখুঁত, আর “+ 50 তারপর পূর্ণসংখ্যার ভাগ” স্পষ্টভাবে “অর্ধেক হলে ওপরে” রাউন্ড করে। কোন রাউন্ডিং নিয়ম মানবেন, তা ব্যবসা বা কর-কর্তৃপক্ষের নিয়ম ঠিক করে — DBMS-এর ডিফল্টের ওপর ছেড়ে দেবেন না, কারণ ডিফল্টগুলো আলাদা:

ABS, CEIL/FLOOR আর ভাগের নিয়ম

abs(x) পরম মান দেয় (abs(-15) = 15) — যেমন হিসাবের অমিল কত টাকা, চিহ্ন বাদে। ceil(x) ওপরের পূর্ণসংখ্যা, floor(x) নিচের: ceil(2.1) = 3, floor(−2.1) = −3. এর চেয়েও বেশি ভুল হয় ভাগে: SQLite, PostgreSQL আর SQL Server-এ দুটি পূর্ণসংখ্যার ভাগ পূর্ণসংখ্যা — ভগ্নাংশ ফেলে দেওয়া হয়, একে বলে integer division. MySQL আর Oracle-এ 7 / 2 = 3.5. গুদামে একটি বাক্সে ১২টি পণ্য ধরে — কয়টি বাক্স লাগবে?

SELECT 7 / 2 AS int_div, 7 / 2.0 AS real_div, 7 % 2 AS remainder,
       typeof(7 / 2) AS t1, typeof(7 / 2.0) AS t2, 7 / 0 AS div_zero;

SELECT name, stock,
       stock / 12        AS full_boxes,
       stock % 12        AS loose,
       ceil(stock / 12.0) AS boxes_needed
FROM products WHERE product_id IN (101, 102, 108);

SELECT CAST('15000' AS INTEGER) + 1 AS a, CAST('12abc' AS INTEGER) AS b,
       CAST(3.99 AS INTEGER) AS c, '10' + 5 AS d, typeof('10' + 5) AS e;

SELECT abs(random()) % 6 + 1 AS dice;

random() একটি ৬৪-বিট দৈব পূর্ণসংখ্যা দেয় (ধনাত্মক বা ঋণাত্মক), তাই abs(random()) % 6 + 1 দিয়ে ১–৬. লটারির ড্র বা পাসওয়ার্ডের মতো নিরাপত্তার কাজে ডেটাবেসের random() নয়, অ্যাপের cryptographic generator ব্যবহার করুন। আর ORDER BY random() LIMIT 1 দিয়ে “একটি দৈব পণ্য” সহজ, কিন্তু বড় টেবিলে প্রতিটি সারিতে দৈব সংখ্যা বানিয়ে সব সাজাতে হয় — লাখো সারিতে ধীর।

typeof() SQLite-এর নিজস্ব ফাংশন: একটি মান আসলে কোন storage class-এ আছে — null, integer, real, text, blob. SQLite-এ একটি কলামে বিভিন্ন সারিতে বিভিন্ন টাইপ থাকতে পারে (type affinity, পর্ব ১৩), তাই সন্দেহজনক ডেটায় SELECT typeof(price), COUNT(*) FROM products GROUP BY 1 চালিয়ে দেখা ভালো অভ্যাস। PostgreSQL বা MySQL-এ কলামের টাইপ কঠোর, সেখানে typeof() নেই (PostgreSQL-এ কাছাকাছি কাজ করে pg_typeof())। CAST-এর আচরণও আলাদা: PostgreSQL-এ CAST('12abc' AS INTEGER) ত্রুটি দেয়, চুপচাপ 12 বানায় না।

৬ · SQLite-এ তারিখ আর সময় — রাখা, পড়া আর যোগ-বিয়োগ

SQLite-এ আলাদা DATE টাইপ নেই। তারিখ রাখার তিনটি স্বীকৃত উপায়, আর SQLite-এর সব date ফাংশন তিনটিই বোঝে:

ISO-8601 ফরম্যাটে বছর আগে, তারপর মাস, তারপর দিন, সবসময় দুই অঙ্কে (০৯, ০১)। এর ফলে সাধারণ লেখার তুলনাই সময়ের তুলনা: '2025-10-09' > '2025-09-30' সত্য। কিন্তু বাংলাদেশে প্রচলিত '09/10/2025' রাখলে '9/10/2025' > '10/9/2025'-ও “সত্য” — প্রথম অক্ষর '9' বড় বলে, তারিখ হিসেবে নয়। SQLite-এর date ফাংশন '01/09/2025' বা শূন্য ছাড়া '2025-9-1' বোঝেই না, NULL দেয়। মূল ফাংশনগুলো:

• date(x) → 'YYYY-MM-DD', time(x) → 'HH:MM:SS', datetime(x) → 'YYYY-MM-DD HH:MM:SS'; x হতে পারে 'now' — এখনকার UTC সময়।
• strftime(format, x) → যেকোনো রূপে: %Y বছর, %m মাস, %d দিন, %H:%M ঘণ্টা-মিনিট, %w সপ্তাহের দিন (০ = রবিবার), %j বছরের কততম দিন, %s Unix সেকেন্ড।
• julianday(x) → Julian day সংখ্যা; unixepoch(x) → Unix epoch সেকেন্ড (SQLite 3.38 থেকে)।
• যেকোনোটির পরে এক বা একাধিক modifier: '+7 days', '-1 month', '+6 hours', 'start of month', 'start of year', 'weekday 5' (পরের শুক্রবার; দিনটি নিজেই শুক্রবার হলে সেদিনই) — বাঁ থেকে ডানে একটির পর একটি প্রয়োগ হয়।

Modifier-এর ক্রম আর মাসের দৈর্ঘ্যই সবচেয়ে বেশি অবাক করে। ধরুন ৩১ জানুয়ারি একটি কিস্তি, পরের কিস্তি “এক মাস পরে”:

এবার অর্ডারের তারিখ থেকে মাস বের করে মাসভিত্তিক অর্ডার গোনা। orders টেবিলে আছে order_id, customer_id, order_date (ISO তারিখ) আর status. GROUP BY-এর পুরো নিয়ম পর্ব ১৮-এ; এখানে শুধু এটুকু জানলেই চলবে যে একই month-এর সারিগুলো এক দলে গোনা হয়:

SELECT order_id, order_date,
       strftime('%Y-%m', order_date)    AS month,
       strftime('%d/%m/%Y', order_date) AS bd_style,
       strftime('%w', order_date)       AS weekday   -- 0 = রবিবার
FROM orders ORDER BY order_id LIMIT 4;

-- মাসভিত্তিক অর্ডার (GROUP BY-এর পূর্বরূপ, পর্ব ১৮)
SELECT strftime('%Y-%m', order_date) AS month, COUNT(*) AS orders
FROM orders GROUP BY month ORDER BY month;

-- ঢাকায় ১ অক্টোবর রাত ২:৩০ = UTC-তে ৩০ সেপ্টেম্বর 20:30
SELECT strftime('%Y-%m', '2025-09-30 20:30:00')             AS utc_month,
       strftime('%Y-%m', '2025-09-30 20:30:00', '+6 hours') AS dhaka_month;

৭ · দুই তারিখের ব্যবধান, বয়সের ফাঁদ আর টাইমজোন

“গ্রাহক কত দিন ধরে আমাদের সাথে?”, “কোন pending অর্ডার কবে পৌঁছানোর কথা?” — দুটিই তারিখের বিয়োগ আর যোগ। 'now' লিখলে প্রতিদিন ফল বদলাবে, তাই এডিটরে একটি নির্দিষ্ট “আজ” — 2025-10-25 — ধরা হয়েছে, যাতে সবার ফল এক হয়:

SELECT name, joined_on,
       julianday('2025-10-25') - julianday(joined_on)                  AS days_raw,
       CAST(julianday('2025-10-25') - julianday(joined_on) AS INTEGER) AS days
FROM customers ORDER BY days DESC LIMIT 4;

SELECT order_id, order_date, date(order_date, '+7 days') AS due_by
FROM orders WHERE status = 'pending';

-- বয়স: 365.25 দিয়ে ভাগ বনাম ক্যালেন্ডারের নিয়ম (জন্ম 2021-01-01, আজ 2024-01-01)
SELECT CAST((julianday('2024-01-01') - julianday('2021-01-01')) / 365.25 AS INTEGER) AS naive,
       (strftime('%Y', '2024-01-01') - strftime('%Y', '2021-01-01'))
       - (strftime('%m-%d', '2024-01-01') < strftime('%m-%d', '2021-01-01')) AS correct;

বয়স হিসাবের সঠিক নিয়ম

বয়স মানে দিন নয়, ক্যালেন্ডারের জন্মদিন পার হয়েছে কি না। নিয়মটি দুই লাইনে: আজকের বছর − জন্মের বছর; তারপর এ বছরের জন্মদিন (%m-%d) এখনো না এলে ১ বিয়োগ। উপরের correct কলামটি ঠিক এটিই করে — তুলনার ফল সত্য হলে 1, মিথ্যা হলে 0. শুধু একটি ক্ষেত্র নিয়মের বাইরে: ২৯ ফেব্রুয়ারির জন্ম। সাধারণ বছরে তাঁর জন্মদিন ২৮ ফেব্রুয়ারি না ১ মার্চ, তা আইন আর প্রতিষ্ঠানভেদে আলাদা হতে পারে — চাকরির বয়সসীমার মতো গুরুত্বপূর্ণ হিসাবে নিয়মটি লিখিতভাবে নিশ্চিত করুন। আর বয়স কখনো কলামে রাখবেন না; জন্মতারিখ রাখুন, বয়স হিসাব করুন — বয়স প্রতিদিন বদলায়, জন্মতারিখ বদলায় না।

টাইমজোন — রাখুন UTC-তে, দেখান ঢাকার সময়ে

বাংলাদেশের সময় UTC + ৬ ঘণ্টা, লেখা হয় +06:00; আন্তর্জাতিক টাইমজোন ডেটাবেসে এর নাম Asia/Dhaka. SQLite-এর 'now' সবসময় UTC দেয়। তাই নিয়ম: একটি ঘটনার মুহূর্ত (অর্ডার দেওয়ার সময়, পেমেন্টের সময়) রাখুন UTC-তে — যেমন '2025-09-30T20:30:00Z' (Z মানে UTC) — আর দেখানোর সময় টাইমজোন অনুযায়ী বদলান: datetime(t, '+6 hours'). ঢাকার ১ অক্টোবর রাত ১২টা আসলে UTC-তে ৩০ সেপ্টেম্বর সন্ধ্যা ৬টা — তাই “১ অক্টোবরের বিক্রি” মানে UTC-তে '2025-09-30 18:00:00' থেকে '2025-10-01 18:00:00'-এর আগ পর্যন্ত। SQLite-এর 'localtime' modifier-ও আছে, কিন্তু সেটি যে কম্পিউটারে কোয়েরি চলছে তার ঘড়ি মানে — সার্ভার বিদেশে হলে ফল বদলে যায়, আর এই পাতায় পাঠকের নিজের ব্রাউজারের টাইমজোন। তাই এডিটরে আমরা স্পষ্ট '+6 hours' লিখেছি।

৮ · PostgreSQL আর MySQL-এ একই কাজ — তুলনা

তারিখ-সময়ের ফাংশনে DBMS-গুলোর পার্থক্য সবচেয়ে বেশি, কারণ SQL standard এখানে দেরিতে এসেছে আর প্রতিটি পণ্য আগেই নিজের পথ বানিয়ে ফেলেছিল। PostgreSQL আর MySQL-এ আসল DATE, TIMESTAMP টাইপ আছে, আর আছে INTERVAL — “৭ দিন” বা “১ মাস”-এর মতো সময়ের দৈর্ঘ্য, যা একটি মান হিসেবে যোগ-বিয়োগ করা যায়। নিচের ব্লকগুলো এই পাতায় চলে না (পাতার ইঞ্জিন SQLite); নিজের PostgreSQL বা MySQL-এ চালিয়ে দেখতে পারেন:

SELECT now(), current_date;              -- timestamptz, date
SELECT date '2025-09-01' + interval '7 days';     -- 2025-09-08 00:00:00
SELECT date '2025-10-09' - date '2025-09-01';     -- 38 (পূর্ণসংখ্যা দিন)
SELECT date_trunc('month', timestamp '2025-09-20 14:30');  -- 2025-09-01 00:00:00
SELECT extract(year FROM date '2025-09-20');      -- 2025
SELECT to_char(date '2025-09-20', 'YYYY-MM');     -- '2025-09'
SELECT timestamptz '2025-09-30 20:30:00+00' AT TIME ZONE 'Asia/Dhaka';
                                                  -- 2025-10-01 02:30:00
SELECT 7 / 2, 7 / 2.0;                            -- 3, 3.5000000000000000

SELECT NOW(), CURDATE();
SELECT DATE_ADD('2025-09-01', INTERVAL 7 DAY);    -- 2025-09-08
SELECT DATEDIFF('2025-10-09', '2025-09-01');      -- 38
SELECT DATE_FORMAT('2025-09-20', '%Y-%m');        -- '2025-09'
SELECT EXTRACT(YEAR FROM '2025-09-20');           -- 2025
SELECT LAST_DAY('2025-02-10');                    -- 2025-02-28
SELECT TIMESTAMPDIFF(YEAR, '2000-10-10', '2025-10-09');  -- 24 (বয়স)
SELECT 7 / 2, 7 DIV 2;                            -- 3.5000, 3

দুটি সূক্ষ্ম পার্থক্য মনে রাখুন। PostgreSQL-এর now() transaction শুরুর মুহূর্ত দেয় — একই transaction-এর সব সারিতে একই সময়, যা সাধারণত সুবিধাজনক; প্রকৃত ঘড়ির জন্য clock_timestamp(). আর SQL Server-এ একই কাজের নাম আরও আলাদা — GETDATE(), DATEADD(day, 7, d), DATEDIFF(day, b, a), LEN(x) (শেষের ফাঁকা জায়গা বাদ দিয়ে গোনে)। উপভাষাগুলোর পুরো তুলনা পর্ব ৩১-এ।

৯ · WHERE-এ ফাংশন — index কেন লুকিয়ে যায়

“সেপ্টেম্বর ২০২৫-এর অর্ডার” — দুইভাবে লেখা যায়, দুটিই একই ৬টি সারি দেয়। কিন্তু ১ কোটি সারির টেবিলে একটি মিলিসেকেন্ডে শেষ হতে পারে, অন্যটি পুরো টেবিল পড়ে। কারণ index. order_date-এর ওপর index মানে সব order_date সাজানো একটি তালিকা (B+ tree, পর্ব ৪০) — অনেকটা অভিধানের মতো, যেখানে শব্দ বর্ণানুক্রমে সাজানো বলে “ক” দিয়ে শুরু শব্দগুলো সরাসরি খুঁজে পাওয়া যায়। কিন্তু প্রশ্ন যদি হয় “যে শব্দগুলোর শেষ অক্ষর ক”, অভিধানের ক্রম কোনো কাজে আসে না — পুরো বই পড়তে হয়।

WHERE-এ কলামকে ফাংশনে মুড়লে ঠিক এটিই ঘটে: index সাজানো আছে order_date অনুযায়ী, strftime('%Y-%m', order_date) অনুযায়ী নয়। DBMS-কে প্রতিটি সারিতে ফাংশন চালিয়ে তুলনা করতে হয় — full table scan. যে শর্ত index দিয়ে সরাসরি খোঁজা যায়, তাকে বলে sargable. SQLite-এর EXPLAIN QUERY PLAN দিয়ে নিজেই দেখুন DBMS কোন পথ বেছে নেয়:

CREATE INDEX idx_orders_date ON orders(order_date);

-- কলাম ফাংশনের ভেতরে: index কাজে লাগে না
EXPLAIN QUERY PLAN
SELECT * FROM orders WHERE strftime('%Y-%m', order_date) = '2025-09';

-- একই প্রশ্ন, কলাম খালি রেখে পরিসর দিয়ে
EXPLAIN QUERY PLAN
SELECT * FROM orders
WHERE order_date >= '2025-09-01' AND order_date < '2025-10-01';

SELECT COUNT(*) AS sept_orders FROM orders
WHERE order_date >= '2025-09-01' AND order_date < '2025-10-01';

একই ছাঁচের আরও উদাহরণ: WHERE price * 1.15 > 1000-এর বদলে WHERE price > 1000 / 1.15 (হিসাবটি ধ্রুবকের দিকে নিন); WHERE substr(phone, 1, 3) = '017'-এর বদলে WHERE phone LIKE '017%' (শুরুর অংশের LIKE অনেক DBMS-এ index ব্যবহার করতে পারে, তবে SQLite-এ collation-এর শর্ত মানলে তবেই)। আর যখন ফাংশনটি এড়ানো যায় না — যেমন ইমেইল বড়-ছোট হাতের অক্ষর নির্বিশেষে খোঁজা — তখন ফাংশনের ফলের ওপরই index বানান: CREATE INDEX idx_email ON users(lower(email)). একে বলে expression index; SQLite 3.9 (২০১৫) থেকে, PostgreSQL-এ বহু আগে থেকে, আর MySQL 8.0.13 থেকে আছে। শর্ত একটিই: ফাংশনটিকে deterministic হতে হবে — একই ইনপুটে সবসময় একই ফল। তাই julianday('now') দিয়ে index বানাতে গেলে SQLite ত্রুটি দেয়: “non-deterministic use of julianday() in an index”. index বাছাই আর EXPLAIN-এর পুরো আলোচনা পর্ব ৪১-এ।

১০ · AI-এর যুগে SQL ফাংশন

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

AI-এর দেওয়া ফাংশন-ভরা কোয়েরি হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি ফাংশন আমার DBMS-এ আছে আর একই অর্থে কাজ করে (length অক্ষর না বাইট? log কোন ভিত্তির?)
• NULL আছে এমন সারিতে ফল দেখেছি — ||, CONCAT আর হিসাবের কলামে
• ভাগে অন্তত একটি দিক দশমিক, আর টাকার হিসাব পয়সায় পূর্ণসংখ্যায়
• তারিখ: মাসের শেষ দিন, অধিবর্ষ, জন্মদিনের আগে-পরে আর মধ্যরাতের সীমানায় পরীক্ষা করেছি
• সময় UTC-তে রাখা, আর রিপোর্টে কোন টাইমজোন ধরা হয়েছে তা স্পষ্ট
• WHERE-এ index-যুক্ত কলাম ফাংশনে মোড়া নয় — EXPLAIN QUERY PLAN-এ দেখে নিয়েছি
• সারির সংখ্যা আর একটি-দুটি সারির মান হাতে হিসাব করে মিলিয়েছি