SQL-এর উপভাষা — MySQL, PostgreSQL, SQLite, SQL Server আর Oracle

১ · উপভাষা কেন — পণ্য আগে এল, standard পরে

পর্ব ১২ থেকে ৩০ পর্যন্ত আপনি যে SQL লিখেছেন, তার প্রায় সবটাই PostgreSQL, MySQL, SQL Server বা Oracle-এ হুবহু চলবে। কিন্তু “প্রায়” শব্দটিই এই পর্বের বিষয়। প্রতিটি DBMS-এর SQL আসলে একটি উপভাষা — মূল ব্যাকরণ এক, কিছু শব্দ আর রীতি আলাদা।

উপভাষার তিনটি মূল কারণ আছে:

Standard-এর সংস্করণগুলো জানা থাকলে বুঝবেন কোন feature কত “নতুন”: SQL-86, SQL-89, SQL-92 (JOIN … ON, CASE, ঘোষিত constraint — আজকের মৌলিক SQL), SQL:1999 (recursive CTE, trigger, boolean), SQL:2003 (window function, MERGE, identity column), SQL:2008 (FETCH FIRST), SQL:2011 (temporal টেবিল), SQL:2016 (JSON), আর SQL:2023 (property graph query). একটি feature standard-এ ঢোকার পরও প্রতিটি DBMS-এ আসতে বছরের পর বছর লাগতে পারে — MySQL-এ window function আর CTE এসেছে ৮.০ সংস্করণে (২০১৮), standard-এ ঢোকার দেড়-দুই দশক পরে।

২ · পাঁচ পরিবার — কে কোথা থেকে এল, কার লাইসেন্স কী

প্রতিটি DBMS-এর ইতিহাস তার উপভাষার চরিত্র ব্যাখ্যা করে। নিচের সারাংশে সংস্করণ নম্বর আর নীতি সময়ের সাথে বদলায় — কাজে লাগানোর আগে অফিসিয়াল নথি দেখে নিন।

লাইসেন্স শুধু দামের প্রশ্ন নয়। GPL সফটওয়্যার নিজের পণ্যের ভেতরে জুড়ে বিতরণ করলে শর্ত মানতে হয় — এ কারণে কিছু কোম্পানি MySQL-এর বাণিজ্যিক লাইসেন্স কেনে; শুধু server-এ চালিয়ে ওয়েব সেবা দিলে সাধারণত সেই শর্ত আসে না। PostgreSQL-এর উদার লাইসেন্সে যে কেউ এটি বদলে নিজের বন্ধ পণ্য বানাতে পারে — তাই অনেক বাণিজ্যিক ও cloud ডেটাবেস ভেতরে PostgreSQL. আর SQLite-এর public domain অবস্থার কারণে কোটি কোটি যন্ত্রে কোনো আইনি ঝামেলা ছাড়াই এটি বসানো যায়। (আইনি সিদ্ধান্তের আগে লাইসেন্সের আসল লেখা পড়ুন বা বিশেষজ্ঞকে জিজ্ঞেস করুন।)

MariaDB বনাম MySQL

Oracle MySQL কিনে নেওয়ার সময় অনেকে এর ভবিষ্যৎ নিয়ে চিন্তিত ছিলেন; Widenius তখন MariaDB শুরু করেন (MySQL নামটি তাঁর মেয়ে My-এর নামে, MariaDB ছোট মেয়ে Maria-র নামে)। শুরুতে MariaDB ছিল MySQL-এর প্রায় হুবহু বদলি, কিন্তু দশ বছরের বেশি সময়ে দুটি আলাদা পথে গেছে: MariaDB-তে RETURNING, sequence আর system-versioned টেবিল আছে; MySQL ৮-এর কিছু feature (যেমন JSON-কে আলাদা binary টাইপে রাখা) MariaDB অন্যভাবে করে — MariaDB-তে JSON আসলে LONGTEXT-এর আরেক নাম। সংস্করণ নম্বরও আর মেলে না। তাই “MySQL-compatible” লেখা দেখলে ধরে নিন মূল অংশ মিলবে, প্রান্ত নয় — হোস্টিং বদলানোর আগে নিজের অ্যাপের পরীক্ষা চালান।

Cloud সংস্করণ — “compatible” মানে হুবহু নয়

Cloud কোম্পানিগুলো এই DBMS-গুলো পরিচালিত সেবা (managed database) হিসেবে চালায়: backup, update আর replication তারা সামলায়। Amazon RDS আর Google Cloud SQL আসল MySQL, PostgreSQL, SQL Server চালায়; Azure SQL Database চলে SQL Server-এর ইঞ্জিনে। আবার Amazon Aurora বা Google AlloyDB নিজেদের storage স্তরের ওপর “MySQL-compatible” বা “PostgreSQL-compatible” — SQL প্রায় একই, কিন্তু কিছু extension, সংস্করণ বা আচরণ আলাদা হতে পারে। একই কথা SQLite-ভিত্তিক নতুন cloud সেবার ক্ষেত্রেও। Cloud ডেটাবেসের বিস্তারিত পর্ব ৬১-এ।

৩ · একই কাজ, পাঁচ রকম লেখা — id, নাম, জোড়া আর প্রথম n সারি

স্বয়ংক্রিয় id

প্রায় প্রতিটি টেবিলে একটি ক্রমিক নম্বরের primary key লাগে (পর্ব ১৩)। Standard-এর রূপ identity column — GENERATED … AS IDENTITY; কিন্তু প্রতিটি DBMS standard-এর আগেই নিজের পথ বানিয়েছিল। একই customers টেবিল পাঁচ রকমে:

CREATE TABLE customers (
  customer_id INT AUTO_INCREMENT PRIMARY KEY,
  name        VARCHAR(100) NOT NULL
);
INSERT INTO customers (name) VALUES ('Rahim Uddin');
SELECT LAST_INSERT_ID();          -- এই connection-এর শেষ নতুন id

CREATE TABLE customers (
  customer_id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  name        VARCHAR(100) NOT NULL
);
-- পুরোনো রীতি: customer_id SERIAL PRIMARY KEY (পেছনে একটি sequence)
INSERT INTO customers (name) VALUES ('Rahim Uddin')
RETURNING customer_id;

CREATE TABLE customers (
  customer_id INTEGER PRIMARY KEY,  -- rowid-এর আরেক নাম, নিজেই বাড়ে
  name        TEXT NOT NULL
);
-- INTEGER PRIMARY KEY AUTOINCREMENT: মোছা id আর কখনো ফেরত দেয় না
INSERT INTO customers (name) VALUES ('Rahim Uddin');
SELECT last_insert_rowid();

CREATE TABLE customers (
  customer_id INT IDENTITY(1, 1) PRIMARY KEY,   -- শুরু 1, ধাপ 1
  name        NVARCHAR(100) NOT NULL
);
INSERT INTO customers (name)
OUTPUT inserted.customer_id
VALUES (N'Rahim Uddin');
-- অথবা: SELECT SCOPE_IDENTITY();

CREATE TABLE customers (
  customer_id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  name        VARCHAR2(100) NOT NULL
);
-- 12c-এর আগে: CREATE SEQUENCE + একটি BEFORE INSERT trigger
INSERT INTO customers (name) VALUES ('Rahim Uddin');

খেয়াল করুন টাইপের নামও বদলেছে: VARCHAR2 Oracle-এর, NVARCHAR (Unicode) SQL Server-এর, NUMBER Oracle-এর। Auto-increment-এর নম্বরে ফাঁক পড়া server DBMS-গুলোতে স্বাভাবিক — ROLLBACK হওয়া INSERT-এর নম্বর সাধারণত ফেরত আসে না, কারণ sequence পেছনে ফেরে না। তাই id-কে “কতজন গ্রাহক” গোনার উপায় ভাববেন না।

নাম উদ্ধৃত করা আর লেখা জোড়া

MySQL-এর || সবচেয়ে বড় ফাঁদ: ডিফল্টে এটি যৌক্তিক OR, তাই SELECT 'a' || 'b' ত্রুটি দেয় না, দেয় 0 — দুটি লেখাকে সংখ্যায় বদলে (দুটিই 0) OR করে। PIPES_AS_CONCAT SQL mode চালু করলে তবেই এটি জোড়া; MySQL ৮.০.১৭ থেকে OR অর্থে || deprecated. SQL Server-এ Microsoft সম্প্রতি (Azure SQL আর SQL Server 2025-এ) || যোগ করেছে বলে জানিয়েছে, তবে পুরোনো সংস্করণে এটি চলে না। SQLite-এ নিচে দুই রূপ আর NULL-এর আচরণ দেখুন। customers টেবিলে (customer_id, name, city, phone, joined_on) Tanvir Ahmed-এর phone আর Imran Hossain-এর city NULL:

SELECT customer_id,
       name || ' (' || city || ')'         AS with_pipes,
       concat(name, ' (', city, ')')       AS with_concat,
       concat_ws(' — ', name, city, phone) AS with_ws
FROM customers
WHERE customer_id IN (1, 5, 7);

প্রথম n সারি — LIMIT, TOP আর FETCH FIRST

“সবচেয়ে দামি ৩টি পণ্য” — পর্ব ১৫-এ LIMIT শিখেছেন। কিন্তু এটি standard নয়: SQL:2008-এর রূপ FETCH FIRST. নিচের ডায়াগ্রামে একটি MySQL কোয়েরিকে ধাপে ধাপে অন্য চারটি DBMS-এ নিয়ে যাওয়া দেখুন। কাজ: মজুত আছে এমন সবচেয়ে দামি ৩টি পণ্য, নামের পাশে শ্রেণির নাম।

একটিই রূপ কি সব জায়গায় চলে? না। FETCH FIRST চলে PostgreSQL, Oracle ১২c+ আর (OFFSET-সহ) SQL Server-এ; MySQL আর SQLite-এ চলে না। LIMIT চলে MySQL, PostgreSQL আর SQLite-এ। এখন একই কোয়েরি SQLite-এ, আর পরের “পাতা” (OFFSET) সহ — products টেবিল (product_id, name, category_id, price, stock) আর categories (category_id, name):

SELECT p.name || ' - ' || c.name AS label, p.price
FROM products p
JOIN categories c ON c.category_id = p.category_id
WHERE p.stock > 0
ORDER BY p.price DESC
LIMIT 3;

-- পরের পাতা: প্রথম ৩টি বাদ দিয়ে পরের ৩টি
SELECT p.name || ' - ' || c.name AS label, p.price
FROM products p JOIN categories c ON c.category_id = p.category_id
WHERE p.stock > 0
ORDER BY p.price DESC
LIMIT 3 OFFSET 3;

অন্য উপভাষার শব্দ SQLite-এ লিখলে কী হয়? DBMS সাধারণত স্পষ্ট ত্রুটি দেয় — প্রথম ঝুড়ির পার্থক্য ধরা এ কারণেই সহজ। এডিটর প্রথম ত্রুটিতে থেমে যায়, তাই ভুল স্টেটমেন্টটি শেষে রাখা হয়েছে:

-- SQLite-এর রূপ: চলে
SELECT name FROM products ORDER BY price DESC LIMIT 1;

-- SQL Server-এর রূপ: SQLite চেনে না
SELECT TOP 3 name FROM products ORDER BY price DESC;

৪ · ফাংশন আর টাইপ — তারিখ, লেখা, boolean আর ভাগ

পর্ব ১৭-এ দেখেছেন তারিখের ফাংশনে DBMS-গুলো সবচেয়ে বেশি আলাদা। এখানে পাঁচটি পাশাপাশি — নামগুলো মুখস্থ করার দরকার নেই, “একই কাজের নাম আলাদা হতে পারে” এই সচেতনতাই আসল।

দুটি সারি বিশেষভাবে মনে রাখুন। COALESCE পাঁচটিতেই আছে — IFNULL, ISNULL, NVL-এর বদলে এটি লিখলে কোড portable থাকে। আর integer division: PostgreSQL, SQLite আর SQL Server-এ দুটি পূর্ণসংখ্যার ভাগ পূর্ণসংখ্যা, MySQL আর Oracle-এ দশমিক। গড় দাম বা শতাংশের রিপোর্ট MySQL থেকে PostgreSQL-এ নিলে ত্রুটি আসবে না — শুধু সংখ্যাগুলো চুপচাপ ছোট হয়ে যাবে। নিরাপদ রূপ: CAST(a AS DECIMAL(12,2)) / b বা a * 1.0 / b. Oracle-এর dual হলো এক সারির একটি বিশেষ টেবিল (DUAL), কারণ পুরোনো Oracle-এ প্রতিটি SELECT-এ FROM বাধ্যতামূলক ছিল।

এবার তারিখের হিসাব SQLite-এর ভাষায়, orders টেবিলে (order_id, customer_id, order_date, status) — উপরের টেবিলের “৭ দিন যোগ”, “ব্যবধান” আর “মাসের শুরু” একসাথে:

SELECT order_id, order_date,
       date(order_date, '+7 days')                     AS due_date,
       date(order_date, 'start of month')              AS month_start,
       julianday('2025-10-09') - julianday(order_date) AS days_before,
       strftime('%Y-%m', order_date)                   AS ym
FROM orders
WHERE order_id IN (1001, 1006, 1010);

৫ · ডেটা লেখার পার্থক্য — UPSERT, MERGE আর RETURNING

“থাকলে হালনাগাদ করো, না থাকলে নতুন ঢোকাও” — একে বলে UPSERT (পর্ব ১৪)। ধরুন গুদামে নতুন চালান এল: পুরোনো পণ্যের মজুত বাড়বে, নতুন পণ্য যোগ হবে। Standard-এর উত্তর MERGE (SQL:2003), কিন্তু MySQL, PostgreSQL আর SQLite আগে নিজের ছোট রূপ বানিয়েছিল:

INSERT INTO products (product_id, name, category_id, price, stock)
VALUES (102, 'Headphone', 1, 1200, 10) AS new
ON DUPLICATE KEY UPDATE stock = stock + new.stock;
-- পুরোনো রূপ: ... UPDATE stock = stock + VALUES(stock)  (৮.০.২০ থেকে deprecated)
-- RETURNING নেই; নতুন id: LAST_INSERT_ID()

INSERT INTO products (product_id, name, category_id, price, stock)
VALUES (102, 'Headphone', 1, 1200, 10)
ON CONFLICT (product_id) DO UPDATE
  SET stock = products.stock + EXCLUDED.stock
RETURNING product_id, stock;
-- PostgreSQL 15 থেকে standard MERGE-ও আছে

INSERT INTO products (product_id, name, category_id, price, stock)
VALUES (102, 'Headphone', 1, 1200, 10)
ON CONFLICT (product_id) DO UPDATE
  SET stock = stock + excluded.stock
RETURNING product_id, stock;
-- সাবধান: INSERT OR REPLACE পুরো সারি মুছে নতুন বসায়

MERGE INTO products AS t
USING (VALUES (102, 'Headphone', 1, 1200, 10))
      AS s (product_id, name, category_id, price, stock)
ON t.product_id = s.product_id
WHEN MATCHED THEN UPDATE SET t.stock = t.stock + s.stock
WHEN NOT MATCHED THEN INSERT (product_id, name, category_id, price, stock)
     VALUES (s.product_id, s.name, s.category_id, s.price, s.stock)
OUTPUT $action, inserted.product_id, inserted.stock;

MERGE INTO products t
USING (SELECT 102 AS product_id, 'Headphone' AS name, 1 AS category_id,
              1200 AS price, 10 AS stock FROM dual) s
ON (t.product_id = s.product_id)
WHEN MATCHED THEN UPDATE SET t.stock = t.stock + s.stock
WHEN NOT MATCHED THEN INSERT (product_id, name, category_id, price, stock)
     VALUES (s.product_id, s.name, s.category_id, s.price, s.stock);

লক্ষ করুন MERGE-এর ON-এ যে শর্ত, ON CONFLICT-এ তার জায়গায় একটি UNIQUE বা PRIMARY KEY লাগে — DBMS সেই index দিয়েই সংঘাত ধরে। আরেকটি বাস্তব সতর্কতা: অনেক সারি একসাথে চললে MERGE নিজে থেকে race condition থেকে মুক্ত নয়; SQL Server-এ অভিজ্ঞরা প্রায়ই উপযুক্ত lock hint যোগ করতে বলেন। এখন SQLite-এ চালিয়ে দেখুন — Headphone (102)-এর মজুত 40, আর 111 নম্বরে কোনো পণ্য নেই:

INSERT INTO products (product_id, name, category_id, price, stock)
VALUES (102, 'Headphone', 1, 1200, 10),
       (111, 'USB Cable', 1,  250, 50)
ON CONFLICT (product_id) DO UPDATE
   SET stock = stock + excluded.stock,
       price = excluded.price;

SELECT product_id, name, price, stock
FROM products WHERE product_id IN (102, 111);

বদলানো সারি ফেরত পাওয়া — RETURNING আর OUTPUT

নতুন অর্ডার ঢোকানোর পর অ্যাপের জানা দরকার এর order_id কত। আলাদা SELECT না চালিয়ে একই স্টেটমেন্টে ফেরত পাওয়ার উপায় হলো RETURNING — PostgreSQL (৮.২ থেকে), SQLite (৩.৩৫ থেকে) আর MariaDB-তে (DELETE-এ, আর ১০.৫ থেকে INSERT-এ)। SQL Server-এ একই কাজ করে OUTPUT inserted.* / deleted.*; Oracle-এ PL/SQL-এর ভেতরে RETURNING … INTO চলক; MySQL-এ নেই — সেখানে LAST_INSERT_ID().

-- নতুন অর্ডার: id DBMS নিজে দেবে, ফেরত চাই
INSERT INTO orders (customer_id, order_date, status)
VALUES (3, '2025-10-10', 'pending')
RETURNING order_id, customer_id, status;

-- বই-শ্রেণিতে ১০% ছাড়: কোন সারি কত হলো?
UPDATE products SET price = price * 0.9
WHERE category_id = 2
RETURNING product_id, name, price;

৬ · নীরব পার্থক্য — নামের বড়-ছোট অক্ষর, তুলনা আর '' বনাম NULL

এবার দ্বিতীয় ঝুড়ি: যে পার্থক্যে কোনো ত্রুটি আসে না। প্রথমটি নামের বড়-ছোট অক্ষর। Standard বলে উদ্ধৃতি ছাড়া লেখা identifier বড় হাতের অক্ষরে বদলে যাবে — একে বলে case folding; Oracle তাই করে। PostgreSQL করে উল্টো — ছোট হাতে, আর এর অফিসিয়াল নথিই বলে এটি standard-এর সাথে মেলে না। উদ্ধৃতির ভেতরের নাম দুই জায়গাতেই হুবহু থাকে:

লেখার তুলনা — collation

নামের নিয়মের চেয়েও বেশি প্রভাব ফেলে ডেটার তুলনা। WHERE city = 'dhaka' কি 'Dhaka'-কে খুঁজে পাবে? উত্তর ঠিক করে collation. MySQL ৮-এর ডিফল্ট collation (utf8mb4_0900_ai_ci) বড়-ছোট অক্ষর আর accent দুটিই উপেক্ষা করে — তাই পাবে। SQL Server-এর প্রচলিত ডিফল্ট collation-ও case-insensitive. PostgreSQL, Oracle আর SQLite ডিফল্টে case-sensitive — পাবে না। MySQL থেকে PostgreSQL-এ যাওয়া একটি লগইন পাতায় হঠাৎ “Rahim@Mail.com” দিয়ে ঢোকা বন্ধ হয়ে যেতে পারে, কোনো ত্রুটি ছাড়াই। সমাধান: তুলনার আগে দুই দিকে lower() (আর তার ওপর expression index), বা PostgreSQL-এ citext টাইপ / ILIKE.

Oracle-এ খালি লেখা মানেই NULL

সবচেয়ে বিখ্যাত নীরব পার্থক্য: Oracle-এ VARCHAR2 কলামে '' (খালি লেখা) রাখলে সেটি NULL হয়ে যায়। পর্ব ১৬-এ শিখেছেন NULL মানে “অজানা”, আর খালি লেখা মানে “জানা, কিন্তু কিছু নেই” — standard আর অন্য চার DBMS এই দুটিকে আলাদা রাখে। একটি contacts টেবিলে (id, phone) তিনটি সারি দিয়ে ধাপে ধাপে দেখুন:

এবার দেখুন এই নীরব পার্থক্যগুলোতে SQLite কোন পথ নিয়েছে — নিজের চোখে, লাইভ এডিটরে:

SELECT '' IS NULL   AS empty_is_null,
       length('')   AS len_empty,
       7 / 2        AS int_div,
       TRUE + TRUE  AS true_sum,
       typeof(TRUE) AS bool_type;

SELECT 'Dhaka' = 'dhaka'                AS binary_cmp,
       'Dhaka' = 'dhaka' COLLATE NOCASE AS nocase_cmp;

SELECT COUNT(*) AS no_phone    FROM customers WHERE phone IS NULL;
SELECT COUNT(*) AS empty_phone FROM customers WHERE phone = '';

৭ · ক্ষমতার পার্থক্য — GROUP BY, recursive CTE, FULL JOIN, procedural ভাষা আর JSON

GROUP BY কতটা কড়া

পর্ব ১৮-এ দেখেছেন, GROUP BY-এ নেই আর aggregate-এর ভেতরেও নেই এমন কলাম SELECT-এ লিখলে কী হয়। Standard বলে — নিষেধ, যদি না কলামটি group-এর কলামের ওপর functionally নির্ভরশীল হয়। SQL Server আর Oracle কড়া: সরাসরি ত্রুটি। PostgreSQL (৯.১ থেকে) ছাড় দেয় শুধু যখন GROUP BY-তে টেবিলের primary key আছে। MySQL ৫.৭.৫ থেকে ONLY_FULL_GROUP_BY ডিফল্টে চালু; তার আগে যেকোনো কলাম চলত, মান আসত দলের যেকোনো সারি থেকে। আর SQLite এখনো ঢিলা — bare column মেনে নেয়:

-- প্রতিটি শ্রেণির সবচেয়ে দামি পণ্য — SQLite-এর বিশেষ সুবিধায়
SELECT category_id, name, MAX(price) AS top_price
FROM products
GROUP BY category_id;

Recursive CTE — RECURSIVE শব্দটি লাগবে কি না

পর্ব ২৫-এর recursive query standard-এ লেখা হয় WITH RECURSIVE দিয়ে; PostgreSQL, MySQL ৮, MariaDB আর SQLite তাই মানে। কিন্তু SQL Server (২০০৫ থেকে) আর Oracle (১১g Release 2 থেকে) recursive CTE লেখে শুধু WITH দিয়ে — SQL Server-এ RECURSIVE লিখলে উল্টো ত্রুটি। Oracle-এর এর চেয়ে পুরোনো নিজস্ব পথও আছে: CONNECT BY PRIOR. SQLite-এ একটি প্রচলিত কাজ — রিপোর্টে যে দিনে অর্ডার নেই, সেই দিনও ০ দিয়ে দেখানো:

WITH RECURSIVE days(d) AS (
  SELECT '2025-09-01'
  UNION ALL
  SELECT date(d, '+1 day') FROM days WHERE d < '2025-09-07'
)
SELECT d AS day, COUNT(o.order_id) AS orders
FROM days LEFT JOIN orders o ON o.order_date = d
GROUP BY d
ORDER BY d;

WITH days (d) AS (                       -- RECURSIVE লেখা যাবে না
  SELECT CAST('2025-09-01' AS date)
  UNION ALL
  SELECT DATEADD(day, 1, d) FROM days WHERE d < '2025-09-07'
)
SELECT d FROM days
OPTION (MAXRECURSION 100);               -- ডিফল্ট সীমা 100 ধাপ

FULL OUTER JOIN

পর্ব ১৯-এর FULL OUTER JOIN PostgreSQL, SQL Server আর Oracle-এ বহু আগে থেকে আছে; SQLite-এ এসেছে ৩.৩৯ (২০২২) সংস্করণে, RIGHT JOIN-সহ। MySQL আর MariaDB-তে এখনো নেই — সেখানে LEFT JOIN আর একটি anti join-এর UNION ALL দিয়ে বানাতে হয়:

SELECT c.name, o.order_id
FROM customers c LEFT JOIN orders o ON o.customer_id = c.customer_id
UNION ALL
SELECT NULL, o.order_id
FROM orders o LEFT JOIN customers c ON c.customer_id = o.customer_id
WHERE c.customer_id IS NULL;     -- শুধু ডান দিকের মিলহীন সারি

Procedural ভাষা আর JSON

SQL নিজে declarative — “কী চাই” বলে। কিন্তু loop, চলক আর শর্তসহ server-এ চলা প্রোগ্রাম (stored procedure, পর্ব ২৮) লিখতে প্রতিটি DBMS নিজের ভাষা বানিয়েছে, আর এখানেই উপভাষা সবচেয়ে বেশি আলাদা — একটির procedure আরেকটিতে প্রায় নতুন করে লিখতে হয়:

JSON-এর standard রূপ (SQL:2016-এর JSON_VALUE, JSON_QUERY ইত্যাদি) এসেছে অনেক DBMS নিজের অপারেটর বানিয়ে ফেলার পরে, তাই ->>-এর মতো সংক্ষিপ্ত রূপ সুবিধাজনক হলেও portable নয়। বিস্তারিত পর্ব ৩০-এ।

৮ · Transaction-এর পার্থক্য — DDL-এর commit আর ডিফল্ট isolation

পর্ব ৪৪-এ transaction বিস্তারিত শিখবেন; এখানে শুধু দুটি পার্থক্য, যা migration স্ক্রিপ্ট লেখার সময়ই কামড়ায়। প্রথমটি: CREATE TABLE বা ALTER TABLE কি ROLLBACK করা যায়? PostgreSQL আর SQLite-এ যায় — একে বলে transactional DDL. তাই দশটি schema বদলের একটি migration-এর মাঝপথে ত্রুটি হলে সব ফিরে যায়। SQL Server-এও বেশিরভাগ DDL transaction-এর ভেতরে ফেরানো যায়। কিন্তু MySQL আর Oracle-এ DDL চালানোর আগে আর পরে নিজে থেকে commit হয় (implicit commit): মাঝপথে থামলে অর্ধেক বদল থেকে যায়। SQLite-এ পরীক্ষা করুন:

BEGIN;
CREATE TABLE coupons (code TEXT PRIMARY KEY, pct INTEGER);
INSERT INTO coupons VALUES ('EID10', 10);
SELECT COUNT(*) AS inside_tx FROM coupons;
ROLLBACK;

-- টেবিলটি কি আছে? SQLite-এর catalog দেখি
SELECT COUNT(*) AS coupons_table_exists
FROM sqlite_master WHERE name = 'coupons';

দ্বিতীয়টি: একসাথে অনেক transaction চললে একটি আরেকটির বদল কতটা দেখবে, তা ঠিক করে isolation level (পর্ব ৪৭)। ডিফল্টগুলো আলাদা, আর একই অ্যাপ এক DBMS থেকে আরেকটিতে নিলে concurrency-র আচরণ চুপচাপ বদলে যায়:

একই নামের level-ও সব DBMS-এ একই আচরণ করে না: PostgreSQL-এর REPEATABLE READ আসলে snapshot isolation, যা MySQL-এর REPEATABLE READ-এর চেয়ে কিছু ক্ষেত্রে কড়া; আর Oracle-এর SERIALIZABLE-ও snapshot-ভিত্তিক, পূর্ণ serializable নয়। কোন anomaly কোথায় সম্ভব, তা পর্ব ৪৭-এর বিষয়; এখানে শুধু মনে রাখুন — “ডিফল্টে চলছে” মানে সব DBMS-এ এক নয়।

৯ · Portable SQL, migration আর বাংলাদেশে DBMS বাছাই

সব পার্থক্য জানার পর প্রশ্ন: এমন SQL কীভাবে লিখবেন যা যতটা সম্ভব সব জায়গায় চলে? একে বলে portable SQL. কয়েকটি অভ্যাস প্রায় বিনা খরচে বেশিরভাগ ঝামেলা দূর করে:

• নাম ছোট হাতে snake_case, কোনো keyword নয় (order, user, date নামের টেবিল/কলাম নয়), কখনো উদ্ধৃতি নয়
• লেখা single quote-এ, NULL-এর বিকল্পে COALESCE, অবস্থাভেদে CASE — IFNULL, NVL, ISNULL, IF() নয়
• JOIN সবসময় JOIN … ON; table alias-এ AS নয়, কলাম alias-এ AS
• ভাগে টাইপ স্পষ্ট (CAST(… AS DECIMAL)), তুলনায় বড়-ছোট অক্ষরের নিয়ম স্পষ্ট (lower()), আর '' দিয়ে NULL বোঝানো নয়
• সংখ্যা সীমিত করা, UPSERT, তারিখ আর id ফেরত পাওয়ার কোড এক জায়গায় (একটি ফাংশন বা repository স্তরে), যাতে বদলাতে হলে এক জায়গাতেই বদলায়
• পরীক্ষা চলে আসল লক্ষ্য DBMS-এ — production PostgreSQL হলে test-ও PostgreSQL-এ

ORM (পর্ব ৫০) — যেমন Django ORM, SQLAlchemy, Hibernate বা Laravel-এর Eloquent — প্রতিটি DBMS-এর জন্য একটি “dialect” স্তর রাখে, যা LIMIT/TOP, quoting, id ফেরত পাওয়া আর টাইপের পার্থক্য নিজে সামলায়। কিন্তু তিনটি জিনিস ORM ঢাকে না: collation আর বড়-ছোট অক্ষরের তুলনা, Oracle-এর '', আর transaction/isolation-এর আচরণ। আর হাতে লেখা raw SQL তো ORM-এর বাইরেই থাকে। একটি প্রচলিত ভুল হলো দ্রুততার জন্য test চালানো SQLite-এ, অথচ production PostgreSQL — test সবুজ, কিন্তু production-এ GROUP BY বা collation-এর ত্রুটি।

MySQL থেকে PostgreSQL — migration-এর চেনা ফাঁদ

বাংলাদেশে অনেক প্রজেক্ট শেয়ার্ড হোস্টিংয়ে MySQL দিয়ে শুরু হয়, পরে VPS বা cloud-এ গিয়ে PostgreSQL-এ সরতে চায়। এই পথের প্রচলিত গর্তগুলো:

লক্ষ করুন, কিছু ফাঁদ ত্রুটি দেয় (ভালো — আপনি জানতে পারেন), কিছু চুপচাপ ফল বদলায় (বিপজ্জনক)। তাই migration-এর আসল পরীক্ষা হলো একই প্রশ্ন দুই DBMS-এ চালিয়ে ফল মেলানো — সারির সংখ্যা, যোগফল, কয়েকটি নির্দিষ্ট সারি। আর একটি পুরোনো সতর্কতা: MySQL ৮.০.১৬-এর আগে CHECK constraint পড়া হতো কিন্তু প্রয়োগ হতো না, তাই পুরোনো MySQL-এর ডেটায় এমন সারি থাকতে পারে যা PostgreSQL-এর CHECK আটকে দেবে। Schema বদলের নিয়ন্ত্রিত পদ্ধতি পর্ব ৫০-এর migration অংশে।

বাংলাদেশে প্রজেক্টের জন্য DBMS বাছাই

“সবচেয়ে ভালো DBMS কোনটি?” প্রশ্নের উত্তর নেই; আছে “এই প্রজেক্টের জন্য কোনটি?” নিচের চারটি প্রশ্ন ক্রমে জিজ্ঞেস করুন:

1. অ্যাপ কোথায় চলবে? মোবাইল বা ডেস্কটপের ভেতরে, ইন্টারনেট ছাড়া — SQLite প্রায় স্বাভাবিক উত্তর। দেশের প্রচলিত cPanel শেয়ার্ড হোস্টিংয়ে সাধারণত MySQL বা MariaDB-ই দেওয়া থাকে; PostgreSQL কিছু হোস্টিংয়ে পাওয়া যায়, তবে VPS বা cloud-এ নিজে চালানোই বেশি প্রচলিত। প্যাকেজ কেনার আগে হোস্টিং কোম্পানির কাছে নিশ্চিত হয়ে নিন।
2. দলের দক্ষতা কী? দলে যে DBMS ভালো জানা আছে, তাতে backup, index আর সমস্যা সমাধান দ্রুত হয়। PHP/Laravel আর WordPress-এর জগতে MySQL-এর অভিজ্ঞতা সহজলভ্য; Django, Node আর Spring-এর জগতে PostgreSQL ক্রমশ বেশি দেখা যায়।
3. প্রতিষ্ঠানে আগে থেকে কী আছে? ব্যাংক, টেলিকম আর বড় প্রতিষ্ঠানে Oracle বা SQL Server প্রায়ই চালু থাকে — নতুন মডিউল সেই সিস্টেমের সাথে জুড়তে হলে, DBA আর লাইসেন্স আগেই থাকলে সেটিই বাস্তব পছন্দ।
4. খরচ আর লাইসেন্স। ছোট ব্যবসা বা স্টার্টআপের জন্য open-source DBMS লাইসেন্সের খরচ বাঁচায়; বাণিজ্যিক DBMS-এ লাইসেন্স সাধারণত CPU core বা ব্যবহারকারী অনুযায়ী, আর বিনা মূল্যের সংস্করণে ডেটার আকার বা CPU-র সীমা থাকে।

চাকরির বাজার নিয়ে একটি সৎ কথা: দেশের চাকরির বিজ্ঞপ্তিতে MySQL, PostgreSQL, Oracle আর SQL Server — চারটির নামই নিয়মিত দেখা যায়, কোনটি কত শতাংশ তার নির্ভরযোগ্য পরিসংখ্যান আমাদের হাতে নেই, তাই কোনো সংখ্যা দিচ্ছি না। ব্যাংক আইটি-র লিখিত পরীক্ষা বা ল্যাবে কোন DBMS ব্যবহার হবে, তা প্রতিষ্ঠানভেদে আলাদা। সবচেয়ে নিরাপদ কৌশল: standard SQL গভীরভাবে শিখুন (এই কোর্সের মূল লক্ষ্য), একটি DBMS-এ হাত পাকান, আর বাকিগুলোর পার্থক্যের এই মানচিত্র মাথায় রাখুন — নতুন উপভাষা তখন কয়েক দিনের অভ্যাস।

১০ · AI-এর যুগে উপভাষা

AI টুল SQL লেখে দ্রুত, কিন্তু উপভাষার ক্ষেত্রে তার একটি নির্দিষ্ট দুর্বলতা আছে: আপনি DBMS আর সংস্করণ না বললে সে প্রায়ই কয়েকটি উপভাষা মিশিয়ে ফেলে — PostgreSQL-এর কোয়েরিতে MySQL-এর IFNULL, SQL Server-এর জন্য LIMIT, বা SQLite-এ নেই এমন ফাংশন। এর চেয়েও সূক্ষ্ম, কোয়েরি চলে কিন্তু নীরব পার্থক্যে (collation, '', integer division) ফল ভুল। নিচের ভুলগুলো সবচেয়ে বেশি দেখা যায়:

AI-এর দেওয়া SQL অন্য DBMS-এ নেওয়ার আগে — চেকলিস্ট

• প্রম্পটে DBMS-এর নাম আর সংস্করণ লিখেছি, আর উত্তরের প্রতিটি ফাংশন সেই সংস্করণে আছে কি না দেখেছি
• LIMIT/TOP/FETCH, জোড়া, তারিখ আর UPSERT-এর রূপ লক্ষ্য DBMS-এর
• নামের উদ্ধৃতি নেই বা লক্ষ্য DBMS-এর নিয়মে আছে; PostgreSQL-এ বড় হাতের উদ্ধৃত নাম নেই
• তুলনার collation, '' বনাম NULL আর ভাগের টাইপ নিয়ে একটি করে পরীক্ষার সারি চালিয়েছি
• DDL-সহ স্ক্রিপ্টে লক্ষ্য DBMS-এ ROLLBACK আসলে কী ফেরায়, তা জেনে নিয়েছি
• দুই DBMS-এ একই প্রশ্নের সারির সংখ্যা আর যোগফল মিলিয়েছি; বড় টেবিলে EXPLAIN দেখে নিয়েছি