ALTER TABLE, constraint আর referential action

১ · Schema কেন বদলায় — নতুন প্রয়োজন, পুরোনো টেবিল

পর্ব ১৩-এ আপনি CREATE TABLE দিয়ে টেবিল বানাতে শিখেছেন, আর পর্ব ৬-এ দেখেছেন key আর constraint কী। কিন্তু বাস্তবে টেবিল একবার বানিয়ে চিরকাল একই থাকে না। দোকান চালু হওয়ার ছয় মাস পর মালিক বললেন: “অর্ডারের রসিদ এখন থেকে গ্রাহকের email-এ যাবে।” customers টেবিলে email কলাম নেই। আবার নতুন টেবিল বানিয়ে আটজন গ্রাহককে নতুন করে ঢোকাবেন? না — এমন কাজের জন্যই আছে ALTER TABLE: চালু টেবিলের নকশা (schema) বদলানোর DDL স্টেটমেন্ট, যাতে ভেতরের ডেটা অক্ষত থাকে।

Schema বদলের কারণ নানা রকম: নতুন ফিচার (email, ডেলিভারি চার্জ), নতুন আইন বা নীতি (ভ্যাটের হার আলাদা কলামে), ভুল ডিজাইন শোধরানো (ফোন নম্বর INTEGER থেকে TEXT), পারফরম্যান্স (index বা derived কলাম), আর নতুন ব্যবসার নিয়ম (CHECK, foreign key). প্রতিটি বদলের তিনটি প্রশ্ন আছে: পুরোনো সারির কী হবে? যারা এই টেবিল ব্যবহার করে (view, কোয়েরি, অ্যাপ) তারা ভাঙবে কি? আর বদলের সময় টেবিল কতক্ষণ আটকে থাকবে? এই পর্ব এই তিন প্রশ্নের উত্তর খোঁজে।

লাইভ SQL চলে দোকানের ডেটাবেসে (db-shop): customers (customer_id, name, city, phone, joined_on — ৮ জন), categories (category_id, name — ৪টি শ্রেণি), products (product_id, name, category_id, price, stock — ১০টি পণ্য), orders (order_id, customer_id, order_date, status — ১০টি অর্ডার) আর order_items (order_id, product_id, quantity, unit_price — ১৬টি লাইন)। কয়েকটি এডিটর নিজের ছোট parent/child টেবিল বানিয়ে নেয়; প্রতিটির “নমুনা ডেটা” বাক্সে schema দেখতে পাবেন। প্রতিবার চালালে ডেটাবেস নতুন করে তৈরি হয়, foreign key চালু থাকে।

২ · ADD COLUMN — নতুন কলাম, DEFAULT আর NOT NULL

সবচেয়ে সাধারণ বদল হলো কলাম যোগ। গঠন সব DBMS-এ প্রায় একই: ALTER TABLE টেবিল ADD COLUMN কলাম টাইপ [constraint];. নতুন কলামটি টেবিলের শেষে বসে, আর পুরোনো প্রতিটি সারিতে তার মান হয় DEFAULT — DEFAULT না দিলে NULL. চলুন দোকানের email-প্রয়োজনটি মেটাই:

-- নতুন প্রয়োজন: রসিদ যাবে email-এ
ALTER TABLE customers ADD COLUMN email TEXT;

-- পুরোনো ৮টি সারিতে email এখন NULL; তিনজনেরটা জানা গেল
UPDATE customers SET email = 'rahim@example.com'  WHERE customer_id = 1;
UPDATE customers SET email = 'karima@example.com' WHERE customer_id = 2;
UPDATE customers SET email = 'nusrat@example.com' WHERE customer_id = 4;

SELECT customer_id, name, email FROM customers;
SELECT COUNT(*) AS total, COUNT(email) AS with_email FROM customers;

NOT NULL কলাম যোগ করতে চাইলে

ধরুন নিয়ম হলো “প্রতিটি গ্রাহক হয় সক্রিয়, নয় নিষ্ক্রিয়” — ঘরটি কখনো ফাঁকা থাকবে না। নতুন কলামে NOT NULL দিলে প্রশ্ন ওঠে: পুরোনো ৮টি সারিতে কী বসবে? DEFAULT থাকলে উত্তর সহজ, না থাকলে DBMS কলামটি যোগ করতেই অস্বীকার করে:

-- DEFAULT আছে: পুরোনো সারিগুলো সেই মান পায়
ALTER TABLE customers ADD COLUMN is_active INTEGER NOT NULL DEFAULT 1;
SELECT customer_id, name, is_active FROM customers WHERE customer_id <= 3;

-- DEFAULT ছাড়া NOT NULL: পুরোনো ৮টি সারিতে কী বসবে?
ALTER TABLE customers ADD COLUMN district TEXT NOT NULL;

SQLite-এর ADD COLUMN-এ আরও কিছু নিয়ম আছে: নতুন কলাম PRIMARY KEY বা UNIQUE হতে পারে না; DEFAULT হিসেবে CURRENT_TIMESTAMP-এর মতো সময়-নির্ভর মান চলে না; আর foreign key চালু থাকলে REFERENCES-ওয়ালা নতুন কলামের DEFAULT NULL হতে হয় (নইলে ত্রুটি Cannot add a REFERENCES column with non-NULL default value). SQLite 3.37.0 (২০২১) থেকে নতুন কলামের CHECK পুরোনো সারিগুলোর ওপরও যাচাই হয়।

৩ · নাম বদল আর কলাম মোছা — RENAME আর DROP COLUMN

কখনো নাম ভুল থাকে: phone আসলে শুধু মোবাইল নম্বর রাখে, দল চায় নাম হোক mobile. কখনো পুরো টেবিলের নাম বদলায়: categories থেকে product_categories. দুটির জন্য স্টেটমেন্ট: ALTER TABLE t RENAME COLUMN a TO b (RENAME COLUMN) আর ALTER TABLE t RENAME TO t2. বড় প্রশ্ন: যারা পুরোনো নামে এই টেবিল ব্যবহার করছিল — একটি view, অন্য টেবিলের foreign key — তাদের কী হবে?

-- পুরোনো নাম phone ব্যবহার করে একটি view
CREATE VIEW dhaka_customers AS
  SELECT customer_id, name, phone FROM customers WHERE city = 'Dhaka';

ALTER TABLE customers RENAME COLUMN phone TO mobile;
ALTER TABLE categories RENAME TO product_categories;

-- view আর products-এর foreign key কি নতুন নাম জানে?
SELECT * FROM dhaka_customers;
SELECT name, sql FROM sqlite_schema
WHERE name IN ('dhaka_customers', 'products');

DROP COLUMN — মোছা সহজ, ফেরানো কঠিন

DROP COLUMN কলামটি তার সব ডেটাসহ মুছে দেয়। PostgreSQL আর MySQL বহু বছর ধরে এটি পারে; SQLite পেয়েছে ৩.৩৫.০ সংস্করণে (২০২১), কয়েকটি শর্তসহ: কলামটি PRIMARY KEY বা তার অংশ হতে পারবে না, UNIQUE হতে পারবে না, কোনো index-এ থাকতে পারবে না, অন্য কলামের CHECK-এ, generated column-এ, trigger-এ বা view-এ ব্যবহৃত হতে পারবে না। এক কথায় — যার ওপর আর কিছু নির্ভর করে, তা সরাসরি মোছা যায় না।

-- joined_on কোনো key, index বা constraint-এ নেই: মোছা যায়
ALTER TABLE customers DROP COLUMN joined_on;
SELECT * FROM customers WHERE customer_id <= 2;

-- phone-এ UNIQUE আছে: SQLite সরাসরি মুছতে দেবে না
ALTER TABLE customers DROP COLUMN phone;

৪ · SQLite-এর সীমিত ALTER আর ১২ ধাপের rebuild

PostgreSQL আর MySQL-এ ALTER TABLE প্রায় সবকিছু পারে: কলামের টাইপ বদল, NOT NULL বসানো-তোলা, DEFAULT বদল, constraint যোগ-বাদ। নিচের ব্লকগুলো তুলনার জন্য — এই পাতায় চালানো যায় না:

ALTER TABLE customers ALTER COLUMN phone TYPE varchar(20);
ALTER TABLE customers ALTER COLUMN city SET NOT NULL;
ALTER TABLE customers ALTER COLUMN city DROP NOT NULL;
ALTER TABLE customers ALTER COLUMN is_active SET DEFAULT true;
ALTER TABLE products  ADD CONSTRAINT products_stock_max CHECK (stock <= 10000);
ALTER TABLE products  DROP CONSTRAINT products_stock_max;
ALTER TABLE orders    ADD CONSTRAINT orders_customer_fk
  FOREIGN KEY (customer_id) REFERENCES customers (customer_id) ON DELETE RESTRICT;

ALTER TABLE customers MODIFY COLUMN phone VARCHAR(20) NULL;
ALTER TABLE customers MODIFY COLUMN city VARCHAR(50) NOT NULL;  -- strict mode-এ NULL থাকলে ব্যর্থ
ALTER TABLE customers RENAME COLUMN phone TO mobile;            -- 8.0 থেকে
ALTER TABLE products  ADD CONSTRAINT products_stock_max CHECK (stock <= 10000);
ALTER TABLE products  DROP CHECK products_stock_max;            -- 8.0.16 থেকে
ALTER TABLE orders    DROP FOREIGN KEY orders_ibfk_1;           -- MySQL-এর নিজের দেওয়া নাম

SQLite-এ এগুলোর কোনোটিই নেই। SQLite-এর ALTER TABLE ঠিক চারটি কাজ পারে: RENAME TO, RENAME COLUMN, ADD COLUMN আর DROP COLUMN. ALTER TABLE customers ADD CONSTRAINT … লিখলে আসে near "CONSTRAINT": syntax error, আর ALTER COLUMN লিখলে near "ALTER": syntax error. কারণটি SQLite-এর গঠনে: সে প্রতিটি টেবিলের schema রাখে মূল CREATE TABLE লেখাটি হিসেবেই, আর ডিস্কের প্রতিটি সারি সেই লেখার কলাম-ক্রম ধরে সাজানো। লেখাটি বদলানো যায়, কিন্তু টাইপ বা constraint বদলালে প্রতিটি সারিও যাচাই বা নতুন করে লিখতে হতে পারে — এই সাধারণ কাজটি SQLite নিজের ভেতরে রাখেনি।

তার বদলে SQLite-এর অফিশিয়াল ডকুমেন্টেশন একটি ১২ ধাপের পদ্ধতি দেয়। মূল ভাবনা সহজ: নতুন নকশায় একটি টেবিল বানানো, পুরোনো ডেটা কপি করা, পুরোনোটি মোছা, নতুনটির নাম বদলে পুরোনো নাম দেওয়া — সব একটি transaction-এর ভেতরে, যাতে মাঝপথে কিছু ভাঙলে পুরোটাই ফিরে যায়। নিচের ডায়াগ্রামে customers টেবিলে city-র জন্য একটি CHECK বসানোর পুরো পথটি দেখুন:

৫ · পুরোনো ডেটায় নতুন constraint — আগে নিয়মভঙ্গকারী খুঁজুন

নতুন নিয়ম: customers-এর city হবে বাংলাদেশের আটটি বিভাগের নামের একটি, ঠিক এই বানানে — Dhaka, Chattogram, Rajshahi, Khulna, Sylhet, Barishal, Rangpur, Mymensingh (অজানা হলে NULL চলবে)। কারণ রিপোর্টে “Ctg” আর “Chattogram” আলাদা শহর হিসেবে গোনা হচ্ছিল। এই এডিটরে db-shop-এর সাথে দুজন নতুন গ্রাহক যোগ হয়েছেন, যাঁদের তথ্য একটি Excel ফাইল থেকে আমদানি করা: (9, 'Sadia Islam', 'Ctg', …) আর (10, 'Rakib Hasan', 'dhaka', …).

যেকোনো DBMS-এ constraint যোগের সময় সেটি পুরোনো সব সারিতে যাচাই হয়; একটি সারিও ভাঙলে পুরো কাজ ব্যর্থ। তাই পেশাদার নিয়ম: constraint বসানোর আগে একটি SELECT দিয়ে দেখুন, কারা নিয়ম ভাঙছে। CHECK শুধু তখনই আটকায়, যখন শর্ত FALSE হয় (NULL হলে UNKNOWN, যা পার পায় — পর্ব ১৬), তাই violator খোঁজার শর্ত হলো WHERE NOT (শর্ত), বা এখানে city NOT IN (…):

-- ১. নিয়ম বসানোর আগে: কোন সারিগুলো নিয়ম ভাঙছে?
SELECT customer_id, name, city FROM customers
WHERE city NOT IN ('Dhaka', 'Chattogram', 'Rajshahi', 'Khulna',
                   'Sylhet', 'Barishal', 'Rangpur', 'Mymensingh');

-- ২. না শুধরেই rebuild শুরু করলে: ধাপ ৫-এর কপি ব্যর্থ
CREATE TABLE customers_new (
  customer_id INTEGER PRIMARY KEY, name TEXT NOT NULL,
  city TEXT CONSTRAINT customers_city_chk CHECK (city IN ('Dhaka', 'Chattogram',
       'Rajshahi', 'Khulna', 'Sylhet', 'Barishal', 'Rangpur', 'Mymensingh')),
  phone TEXT UNIQUE, joined_on TEXT NOT NULL);
INSERT INTO customers_new SELECT * FROM customers;

এখন ডেটা শোধরান — Sadia চট্টগ্রামের, Rakib ঢাকার — তারপর পুরো ১২ ধাপের rebuild চালান। এবার প্রতিটি ধাপ পার হওয়ার কথা:

UPDATE customers SET city = 'Chattogram' WHERE city = 'Ctg';
UPDATE customers SET city = 'Dhaka' WHERE city = 'dhaka';
PRAGMA foreign_keys = OFF;
BEGIN;
CREATE TABLE customers_new (
  customer_id INTEGER PRIMARY KEY, name TEXT NOT NULL,
  city TEXT CONSTRAINT customers_city_chk CHECK (city IN ('Dhaka', 'Chattogram',
       'Rajshahi', 'Khulna', 'Sylhet', 'Barishal', 'Rangpur', 'Mymensingh')),
  phone TEXT UNIQUE, joined_on TEXT NOT NULL);
INSERT INTO customers_new SELECT * FROM customers;
DROP TABLE customers;
ALTER TABLE customers_new RENAME TO customers;
PRAGMA foreign_key_check;
COMMIT;
PRAGMA foreign_keys = ON;
SELECT city, COUNT(*) AS n FROM customers GROUP BY city;

Constraint-এর নাম — কেন নিজে দেবেন

নাম না দিলে DBMS নিজে একটি নাম বানায়: PostgreSQL-এ products_price_check, orders_customer_id_fkey, customers_pkey; MySQL-এ products_chk_1, orders_ibfk_1. এই নামগুলো DBMS-ভেদে আলাদা, আর একই migration দুটি সার্ভারে আলাদা ক্রমে চললে আলাদা নামও পেতে পারে। অথচ constraint মুছতে বা বদলাতে নামটিই লাগে: ALTER TABLE products DROP CONSTRAINT products_price_check. তাই পেশাদার দলগুলো একটি নামকরণ-রীতি মানে, যেমন <টেবিল>_<কলাম>_chk, <টেবিল>_<কলাম>_fk. নাম থাকলে ত্রুটি-বার্তাও পড়া যায়, যেমন উপরে দেখলেন। SQLite-এ নাম দেওয়া যায়, কিন্তু নাম ধরে constraint মোছার স্টেটমেন্ট নেই — সেখানেও rebuild.

৬ · Deferrable constraint — যাচাই commit-এর সময়

সাধারণত constraint যাচাই হয় প্রতিটি স্টেটমেন্টের সাথে সাথে। কিন্তু কিছু বৈধ কাজ মাঝপথে কিছুক্ষণের জন্য নিয়ম ভাঙে। ক্লাসিক উদাহরণ বৃত্তাকার সম্পর্ক: প্রতিটি বিভাগের একজন প্রধান থাকবেন, যিনি একজন কর্মী (departments.head_id → employees), আর প্রতিটি কর্মী কোনো একটি বিভাগে (employees.dept_id → departments) — দুটিই NOT NULL. নতুন অফিস খুললে প্রথম বিভাগ আর তার প্রধান — কাকে আগে ঢোকাবেন? বিভাগ আগে ঢোকালে প্রধান নেই; প্রধান আগে ঢোকালে বিভাগ নেই। ডিম আগে না মুরগি!

সমাধান deferrable constraint: DEFERRABLE INITIALLY DEFERRED লিখলে যাচাই পিছিয়ে যায় transaction-এর শেষে, COMMIT-এর মুহূর্তে। মাঝখানে নিয়ম ভাঙা চলে; COMMIT-এর সময় সব ঠিক থাকলেই হলো। SQLite-এ শুধু foreign key-ই deferrable হতে পারে; PostgreSQL-এ foreign key, UNIQUE, PRIMARY KEY আর EXCLUDE পারে (CHECK আর NOT NULL পারে না); Oracle-ও সমর্থন করে; MySQL আর SQL Server করে না।

-- বিভাগ আর তার প্রধান: একসাথে, একটি transaction-এ
BEGIN;
INSERT INTO departments VALUES (1, 'Accounts', 10);  -- কর্মী 10 এখনো নেই
INSERT INTO employees   VALUES (10, 'Rina Das', 1);
COMMIT;
SELECT d.name AS department, e.name AS head
FROM departments d JOIN employees e ON e.emp_id = d.head_id;

-- যাচাই হয় COMMIT-এ: অস্তিত্বহীন প্রধান 99
BEGIN;
INSERT INTO departments VALUES (2, 'Sales', 99);
COMMIT;

-- PostgreSQL: DEFERRABLE INITIALLY IMMEDIATE = সাধারণত সঙ্গে সঙ্গে যাচাই,
-- কিন্তু দরকার হলে একটি transaction-এর জন্য পিছানো যায়
ALTER TABLE departments ADD CONSTRAINT departments_head_fk
  FOREIGN KEY (head_id) REFERENCES employees (emp_id)
  DEFERRABLE INITIALLY IMMEDIATE;

BEGIN;
SET CONSTRAINTS departments_head_fk DEFERRED;
-- ... বৃত্তাকার INSERT ...
COMMIT;

Deferral-এর আরও দুটি পরিচিত কাজ: (১) একটি UNIQUE কলামে দুটি মান অদলবদল — ক্লাসের রোল 5 আর 6 অদলবদল করলে মাঝপথে দুজনেরই রোল 6 হয়ে যায়; deferrable UNIQUE হলে এটি একটি transaction-এ চলে। (২) বড় ডেটা আমদানি, যেখানে child-এর ফাইল parent-এর ফাইলের আগে আসে। SQLite-এ সব foreign key একটি transaction-এর জন্য পিছাতে আছে PRAGMA defer_foreign_keys = ON.

৭ · Referential action গভীরে — CASCADE থেকে NO ACTION

পর্ব ৬-এ referential action-এর পরিচয় পেয়েছেন: parent সারি মুছলে (ON DELETE) বা তার key বদলালে (ON UPDATE) child সারির কী হবে। পাঁচটি বিকল্প: CASCADE (child-ও মোছে বা বদলায়), SET NULL (child-এর foreign key NULL), SET DEFAULT (child-এর foreign key তার DEFAULT মান পায়), RESTRICT আর NO ACTION (দুটিই child থাকলে আটকায়)। নিচের ডায়াগ্রামে একই ছোট টেবিলে একটি একই DELETE পাঁচটি নিয়মে কী করে, পাশাপাশি দেখুন:

এবার আসল SQLite-এ। এই এডিটরের ছোট schema: categories(category_id, name), products(product_id, name, category_id) — ON DELETE SET NULL — আর banners(banner_id, title, category_id), অর্থাৎ ওয়েবসাইটের প্রথম পাতায় একটি শ্রেণির বিজ্ঞাপন-ব্যানার — ON DELETE CASCADE. শ্রেণি না থাকলে তার ব্যানারের কোনো অর্থ নেই, কিন্তু পণ্যের আছে:

-- Books (2) শ্রেণি বন্ধ: পণ্য থাকবে, ব্যানার যাবে
DELETE FROM categories WHERE category_id = 2;

SELECT * FROM products;
SELECT * FROM banners;

SET DEFAULT-এর একটি ফাঁদ আছে: ডিফল্ট মানটিও একটি foreign key মান, তাই সেটিরও parent থাকতে হয়। এই এডিটরে products.category_id-এর DEFAULT 0 (Uncategorized), নিয়ম ON DELETE SET DEFAULT:

-- Books (2) মুছলে বইগুলো যায় ডিফল্ট শ্রেণি 0-তে
DELETE FROM categories WHERE category_id = 2;
SELECT p.product_id, p.name, c.name AS category
FROM products p JOIN categories c ON c.category_id = p.category_id;

-- এবার ডিফল্ট শ্রেণি 0 নিজেই মুছলে?
DELETE FROM categories WHERE category_id = 0;

RESTRICT বনাম NO ACTION — পার্থক্য শুধু সময়ে

SQL standard অনুযায়ী RESTRICT যাচাই করে সঙ্গে সঙ্গে, প্রতিটি সারি বদলের মুহূর্তে; NO ACTION যাচাই করে স্টেটমেন্টের শেষে, আর constraint deferred হলে COMMIT-এ। পার্থক্যটি চোখে পড়ে তখনই, যখন মাঝখানে কিছু অবস্থাটি শুধরে দেয়। এই এডিটরে দুটি child: orders (ON DELETE NO ACTION) আর payments (ON DELETE RESTRICT), দুটিই DEFERRABLE INITIALLY DEFERRED. Rahim (1)-এর একটি অর্ডার, Karima (2)-এর একটি পেমেন্ট আছে। কাজ: গ্রাহকের সারি মুছে সংশোধিত তথ্যসহ আবার ঢোকানো — যা আমদানি-স্ক্রিপ্ট আর REPLACE INTO ভেতরে ভেতরে করে:

-- Rahim-এর অর্ডার আছে (NO ACTION): মুছে আবার ঢোকানো চলে
BEGIN;
DELETE FROM customers WHERE id = 1;
INSERT INTO customers VALUES (1, 'Rahim Uddin');
COMMIT;
SELECT * FROM customers;

-- Karima-র পেমেন্ট আছে (RESTRICT): deferred হলেও সঙ্গে সঙ্গে আটকায়
BEGIN;
DELETE FROM customers WHERE id = 2;

৮ · Cascade-এর শিকল আর সম্পর্ক বুঝে action বাছাই

CASCADE এক স্তরে থামে না: child নিজে আরেকটি টেবিলের parent হলে ঢেউ সেখানেও যায়। ধরুন কেউ “সুবিধার জন্য” db-shop-এর সব foreign key-তে CASCADE দিয়েছেন — products.category_id → categories আর order_items.product_id → products. এখন অ্যাডমিন প্যানেলে কেউ Electronics শ্রেণিটি “পুরোনো” ভেবে মুছে দিলেন:

প্রতিটি সম্পর্কের জন্য একটি প্রশ্ন

action বাছাইয়ের সবচেয়ে কাজের প্রশ্ন: “parent না থাকলে child-এর কি নিজের অর্থ, ইতিহাস বা আইনি মূল্য আছে?” উত্তর থেকে নিয়ম আসে:

ON UPDATE-এর ক্ষেত্রে বাস্তব পরামর্শ আরও সহজ: surrogate primary key (পর্ব ৬) কখনো বদলায় না, তাই ON UPDATE-এর প্রশ্নই ওঠে না; ডিফল্ট NO ACTION রাখুন। ON UPDATE CASCADE লাগছে মানে key-টি সম্ভবত স্থির নয় — ডিজাইন আবার ভাবুন। আর একটি ব্যবহারিক কথা: CASCADE বা SET NULL চালাতে DBMS-কে child টেবিলে foreign key কলাম ধরে খুঁজতে হয়; সেখানে index না থাকলে প্রতিটি parent মোছায় পুরো child টেবিল পড়া হয় (পর্ব ৪১)।

৯ · Production-এ schema বদল — lock, বড় টেবিল আর migration

এই পাতার ১০ সারির টেবিলে ALTER চোখের পলকে শেষ। কিন্তু একটি চালু ই-কমার্স সাইটের orders টেবিলে কয়েক কোটি সারি থাকতে পারে, আর প্রতি সেকেন্ডে নতুন অর্ডার আসে। সেখানে ALTER-এর দুটি খরচ: সময় — কিছু বদলে DBMS পুরো টেবিল নতুন করে লেখে (table rewrite) বা প্রতিটি সারি যাচাই করে; আর lock — সেই সময়ে টেবিলে লেখা, কখনো পড়াও, আটকে থাকে। PostgreSQL-এ বেশিরভাগ ALTER TABLE সবচেয়ে কড়া lock (ACCESS EXCLUSIVE) নেয়। এমন টেবিলে একটি ঘণ্টা-ব্যাপী ALTER মানে ঘণ্টাখানেক কোনো অর্ডার নেওয়া যাবে না — ঈদের আগের রাতে যা দুঃস্বপ্ন।

যে বদল DBMS নিজে “online” করতে পারে না, তার জন্য বড় MySQL ব্যবহারকারীরা online schema change টুল ব্যবহার করেন — পরিচিত উদাহরণ pt-online-schema-change (Percona Toolkit-এর অংশ) আর gh-ost (GitHub-এর তৈরি, open source). দুটির মূল কৌশল একই — একটি ছায়া-টেবিল:

Lock-এর লাইন — ছোট ALTER-ও বিপদ ঘটাতে পারে

PostgreSQL-এ একটি সূক্ষ্ম ফাঁদ: দ্রুত ALTER-ও (যেমন NULL-যোগ্য কলাম যোগ) ACCESS EXCLUSIVE lock চায়। কোনো দীর্ঘ রিপোর্ট-কোয়েরি টেবিলটি পড়তে থাকলে ALTER অপেক্ষা করে — আর ALTER-এর পেছনে লাইনে দাঁড়িয়ে যায় অ্যাপের সব নতুন কোয়েরি, এমনকি সাধারণ SELECT-ও। এক মিলিসেকেন্ডের কাজ সাইট কয়েক মিনিট বন্ধ করে দিতে পারে। প্রচলিত প্রতিকার: ALTER-এর আগে SET lock_timeout = '2s' — lock না পেলে ALTER নিজে সরে যায়, পরে আবার চেষ্টা।

Migration — schema বদল কোড হিসেবে

পেশাদার দলে কেউ production সার্ভারে হাতে ALTER লেখেন না। প্রতিটি schema বদল একটি migration ফাইল — ক্রমিক নম্বরসহ, version control-এ (যেমন git) রাখা, code review হয়, আর development, test ও production-এ একই ক্রমে চলে। ডেটাবেসের একটি ছোট টেবিল মনে রাখে কোন migration চলেছে। Flyway, Liquibase, Alembic (Python), Rails বা Laravel-এর migration এই ধারণার পরিচিত রূপ — বিস্তারিত পর্ব ৫০-এ।

-- migration 0007: গ্রাহকের email (up)
ALTER TABLE customers ADD COLUMN email TEXT;
CREATE UNIQUE INDEX customers_email_uq ON customers (email);

-- ফেরার পথ (down) — আলাদা ফাইলে বা একই ফাইলের নিচে
-- DROP INDEX customers_email_uq;
-- ALTER TABLE customers DROP COLUMN email;

চালু অ্যাপে নাম বদল বা কলাম মোছার নিরাপদ কৌশল expand–contract (বা parallel change): প্রথমে বাড়ান — নতুন কলাম যোগ, অ্যাপ দুই কলামেই লেখে, পুরোনো ডেটা backfill; তারপর পড়া নতুন কলাম থেকে; সব অ্যাপ-সংস্করণ নতুন কলামে চলে গেলে তবে সংকোচন — পুরোনো কলাম মোছা। প্রতিটি ধাপ আলাদা migration, আর প্রতিটির পরে অ্যাপের পুরোনো ও নতুন দুই সংস্করণই চলতে পারে।

১০ · AI-এর যুগে schema বদল

“customers টেবিলে email যোগ করে UNIQUE বানাও” — AI কয়েক সেকেন্ডে ALTER লিখে দেয়। সমস্যা হলো, ALTER-এর ভুল প্রায়ই চুপচাপ থাকে, আর production-এ একবার চললে ফেরানো কঠিন। AI-এর সাধারণ ভুলগুলো:

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

• আমার DBMS আর সংস্করণে প্রতিটি স্টেটমেন্ট আছে কি না নিশ্চিত হয়েছি (SQLite-এ ADD CONSTRAINT নেই)
• নতুন constraint-এর violator গুনেছি, আর NULL কীভাবে আচরণ করবে বুঝেছি
• production ডেটার একটি কপিতে migration চালিয়ে সময় মেপেছি, সারির সংখ্যা আগে-পরে মিলিয়েছি
• rebuild-এর পরে PRAGMA foreign_key_check খালি, আর view/index/trigger আবার আছে
• প্রতিটি ON DELETE নিয়মের পক্ষে এক লাইনের ব্যবসায়িক যুক্তি আছে
• ফেরার পথ (down migration বা backup) পরীক্ষা করা আছে