Trigger — নিয়ম মেনে স্বয়ংক্রিয় কাজ

১ · Trigger কী — ঘটনা, শর্ত আর কাজ

পর্ব ১৩-এ দেখেছেন, CHECK আর NOT NULL একটি সারির ভেতরের নিয়ম পাহারা দেয়; পর্ব ৬ আর ২৩-এ দেখেছেন, foreign key দুই টেবিলের সম্পর্ক রক্ষা করে। কিন্তু কিছু নিয়ম এর বাইরে পড়ে। “দাম বদলালে পুরোনো দামটি ইতিহাসের খাতায় লিখে রাখো।” “অর্ডারে পণ্য যোগ হলে গুদামের স্টক কমাও।” “অর্ডারের অবস্থা delivered থেকে আর pending-এ ফিরবে না।” এগুলো শুধু “এই মানটি বৈধ কি না” নয় — এগুলো ঘটনার প্রতিক্রিয়া। এমন প্রতিক্রিয়ার জন্যই trigger: ডেটাবেসে রাখা একটি কোড, যা নির্দিষ্ট টেবিলে নির্দিষ্ট পরিবর্তন হলে DBMS নিজে চালায়।

গবেষকেরা এই ধারণাকে বলেন event-condition-action (ECA) নিয়ম। তিনটি অংশ: ঘটনা (কোন টেবিলে কোন পরিবর্তন — INSERT, UPDATE, নির্দিষ্ট কলামের UPDATE, বা DELETE), শর্ত (ঘটনা ঘটলেও কাজটি কি করতে হবে? — WHEN), আর কাজ (এক বা একাধিক SQL স্টেটমেন্ট, BEGIN … END-এর ভেতরে)। নিচের ডায়াগ্রামে একটি দাম বদলের UPDATE-এ তিনটি অংশ একে একে দেখুন:

UPDATE products SET price = 585 WHERE product_id = 104;

-- DBMS খোঁজে: products-এ UPDATE-এ কে কে কান পেতে আছে?
trg_price_audit   AFTER UPDATE OF price ON products

OLD = (104, 'DSA Book', 2, 650, 25)   -- বদলের আগে
NEW = (104, 'DSA Book', 2, 585, 25)   -- বদলের পরে

WHEN NEW.price <> OLD.price
     585       <> 650        →  TRUE

INSERT INTO price_history (product_id, old_price, new_price)
VALUES (OLD.product_id, OLD.price, NEW.price);

price_history:  (104, 650, 585, '…সময়…')

UPDATE products SET price = 15000 WHERE product_id = 101;

OLD.price = 15000, NEW.price = 15000
WHEN 15000 <> 15000  →  FALSE  → কাজ বাদ, ইতিহাসে কিছু লেখা হয় না

দুটি জিনিস মনে রাখুন। প্রথমত, trigger-কে কেউ সরাসরি ডাকে না, তার কোনো parameter নেই — এখানেই পর্ব ২৮-এর stored procedure-এর সাথে পার্থক্য, যাকে নাম ধরে ডাকতে হয়। দ্বিতীয়ত, trigger যে পথেই ডেটা বদলাক — ওয়েবসাইট, মোবাইল অ্যাপ, অ্যাডমিনের হাতে লেখা SQL, রাতের স্ক্রিপ্ট — সবার জন্য চলে। নিয়মটি অ্যাপে নয়, ডেটার পাশে বসে আছে।

২ · প্রথম trigger — দামের প্রতিটি বদল খাতায় লেখা

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

প্রথম কাজ audit log: দাম বদলের পূর্ণ ইতিহাস। ভ্যাট বা ভোক্তা-অধিকারের কোনো প্রশ্নে দোকানকে দেখাতে হতে পারে, কোন দিন কোন পণ্যের দাম কত ছিল। এই এডিটরে আগে থেকে একটি খালি টেবিল বানানো আছে — price_history (product_id, old_price, new_price, changed_at; শেষটির DEFAULT CURRENT_TIMESTAMP, অর্থাৎ লেখার মুহূর্তের UTC সময়)। trigger-এর গঠন লাইন ধরে পড়ুন:

CREATE TRIGGER trg_price_audit
AFTER UPDATE OF price ON products        -- ঘটনা: price কলামের UPDATE
FOR EACH ROW                             -- প্রতিটি বদলানো সারির জন্য একবার
WHEN NEW.price <> OLD.price               -- শর্ত: দাম সত্যিই বদলেছে
BEGIN                                    -- কাজ
  INSERT INTO price_history (product_id, old_price, new_price)
  VALUES (OLD.product_id, OLD.price, NEW.price);
END;

UPDATE products SET price = price * 0.9 WHERE category_id = 2;  -- বইয়ে ১০% ছাড়
UPDATE products SET stock = stock - 1 WHERE product_id = 101;   -- দাম নয়, স্টক
UPDATE products SET price = 15000 WHERE product_id = 101;       -- একই দাম

SELECT product_id, old_price, new_price, changed_at IS NOT NULL AS has_time
FROM price_history;

গঠনটি সাধারণ রূপে: CREATE TRIGGER নাম {BEFORE | AFTER | INSTEAD OF} {INSERT | UPDATE [OF কলাম, …] | DELETE} ON টেবিল [FOR EACH ROW] [WHEN শর্ত] BEGIN স্টেটমেন্ট; … END;. মুছতে DROP TRIGGER নাম. টেবিল মুছলে তার trigger-ও মুছে যায়। আর NEW ও OLD সব ঘটনায় থাকে না — যুক্তিটি সহজ:

৩ · BEFORE, AFTER আর INSTEAD OF — কোন মুহূর্তে চলে

একটি INSERT বাইরে থেকে এক মুহূর্তের কাজ মনে হয়, কিন্তু ভেতরে কয়েকটি ধাপ আছে। BEFORE trigger চলে সারি টেবিলে লেখার আগে, এমনকি NOT NULL, CHECK আর PRIMARY KEY যাচাইয়েরও আগে। AFTER trigger চলে সারি লেখা আর যাচাই শেষ হওয়ার পরে। নিচের ডায়াগ্রামে একটি অর্ডার-লাইন ঢোকানোর পুরো সময়রেখা দেখুন — অর্ডার 1006-এ আগে থেকে একটি লাইন আছে (Smart Watch), এখন দুটি DSA Book যোগ হচ্ছে:

এবার আসল SQLite-এ একই পরীক্ষা। দুটি trigger একটি ছোট timing_log টেবিলে লিখবে — কোন মুহূর্ত, NEW.quantity কত, আর তখন অর্ডার 1006-এর কয়টি লাইন টেবিলে:

CREATE TABLE timing_log (step TEXT, new_qty INTEGER, lines_now INTEGER);
CREATE TRIGGER trg_before BEFORE INSERT ON order_items
BEGIN
  INSERT INTO timing_log SELECT 'BEFORE', NEW.quantity,
    (SELECT COUNT(*) FROM order_items WHERE order_id = NEW.order_id);
END;
CREATE TRIGGER trg_after AFTER INSERT ON order_items
BEGIN
  INSERT INTO timing_log SELECT 'AFTER', NEW.quantity,
    (SELECT COUNT(*) FROM order_items WHERE order_id = NEW.order_id);
END;
INSERT INTO order_items VALUES (1006, 104, 2, 650);
SELECT * FROM timing_log;

INSTEAD OF — view-এর জন্য বিকল্প কাজ

তৃতীয় সময় INSTEAD OF: মূল কাজটি হয়ই না, তার বদলে trigger-এর কাজ হয়। SQLite-এ এটি শুধু view-এর ওপর বানানো যায়, আর BEFORE/AFTER শুধু টেবিলের ওপর। পর্ব ২৪-এ দেখেছেন, JOIN বা GROUP BY-ওয়ালা view-এ সরাসরি INSERT/UPDATE/DELETE চলে না — SQLite-এ কোনো view-ই সরাসরি লেখা যায় না। INSTEAD OF trigger বলে দেয়, “এই view-এ কেউ DELETE চালালে আসলে কোন টেবিলে কী করতে হবে।” অংশ ৭-এ এ দিয়ে soft delete বানাবেন।

Row-level বনাম statement-level

UPDATE products SET price = price * 0.9 WHERE category_id = 2 দুটি সারি বদলেছে, আর trg_price_audit দুবার চলেছে — প্রতি সারিতে একবার। একে বলে row-level trigger (FOR EACH ROW). SQLite-এ শুধু এটিই আছে; FOR EACH ROW না লিখলেও অর্থ একই। SQL standard, PostgreSQL, Oracle আর DB2-তে আরেক রকম আছে: statement-level trigger (FOR EACH STATEMENT), যা একটি স্টেটমেন্টে একবারই চলে — শূন্য সারি বদলালেও। বড় UPDATE-এ এটি অনেক সস্তা, কারণ এক লাখ সারির জন্য trigger এক লাখবার না চলে একবার চলে। Standard, PostgreSQL (১০ থেকে) আর DB2-তে এটি বদলানো সব সারি একসাথে একটি টেবিল হিসেবেও দেখতে পারে (Oracle-এর সাধারণ statement-level trigger পারে না) — একে বলে transition table (REFERENCING OLD TABLE AS … NEW TABLE AS …)। SQL Server-এ trigger শুধুই statement-level, আর বদলানো সারিগুলো আসে inserted ও deleted নামের দুটি ছদ্ম-টেবিলে। MySQL উল্টো: শুধু row-level.

অন্য DBMS-এ একই কাজ কেমন দেখায়, নিচের ট্যাবে দেখুন — এগুলো তুলনার জন্য, এই পাতায় চালানো যায় না। PostgreSQL-এ trigger দুই ভাগে: আগে একটি trigger function (RETURNS trigger, সাধারণত PL/pgSQL-এ), তারপর CREATE TRIGGER … EXECUTE FUNCTION দিয়ে সেটিকে টেবিলের সাথে জোড়া। একই function একাধিক টেবিলে কাজে লাগানো যায়।

CREATE FUNCTION set_updated_at() RETURNS trigger
LANGUAGE plpgsql AS $$
BEGIN
  NEW.updated_at := now();   -- BEFORE trigger NEW বদলাতে পারে
  RETURN NEW;                -- NULL ফেরালে সারিটি বাদ পড়ত
END;
$$;

CREATE TRIGGER trg_products_touch
BEFORE UPDATE ON products
FOR EACH ROW
EXECUTE FUNCTION set_updated_at();   -- PostgreSQL 11-এর আগে: EXECUTE PROCEDURE

CREATE FUNCTION log_price_batch() RETURNS trigger
LANGUAGE plpgsql AS $$
BEGIN
  INSERT INTO price_history (product_id, old_price, new_price)
  SELECT o.product_id, o.price, n.price
  FROM old_rows o JOIN new_rows n USING (product_id)
  WHERE o.price <> n.price;
  RETURN NULL;               -- AFTER trigger-এর ফেরত মান উপেক্ষিত
END;
$$;

CREATE TRIGGER trg_price_audit_stmt
AFTER UPDATE ON products
REFERENCING OLD TABLE AS old_rows NEW TABLE AS new_rows
FOR EACH STATEMENT
EXECUTE FUNCTION log_price_batch();

DELIMITER //
CREATE TRIGGER trg_stock_check
BEFORE INSERT ON order_items
FOR EACH ROW
BEGIN
  -- MySQL-এ WHEN নেই; শর্ত লিখতে হয় IF দিয়ে
  IF NEW.quantity > (SELECT stock FROM products
                     WHERE product_id = NEW.product_id) THEN
    SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'not enough stock';
  END IF;
END//
DELIMITER ;

CREATE TRIGGER trg_price_audit ON products
AFTER UPDATE
AS
BEGIN
  SET NOCOUNT ON;
  -- একবারই চলে; বদলানো সব সারি inserted/deleted-এ
  INSERT INTO price_history (product_id, old_price, new_price)
  SELECT d.product_id, d.price, i.price
  FROM deleted d JOIN inserted i ON i.product_id = d.product_id
  WHERE i.price <> d.price;
END;

কয়েকটি পার্থক্য খেয়াল করুন। PostgreSQL-এর row-level BEFORE function যা ফেরত দেয়, সেটিই লেখা হয় — NEW বদলে ফেরত দিলে বদলানো সারি, NULL দিলে সারিটি নীরবে বাদ। transition table-এর সাথে UPDATE OF কলাম লেখা যায় না, তাই সেখানে শর্ত WHERE-এ। MySQL-এর DELIMITER // কোনো SQL নয় — mysql client-কে বলা, “trigger-এর ভেতরের ; দেখে স্টেটমেন্ট শেষ ভেবো না।” MySQL-এ ত্রুটি তোলা হয় SIGNAL SQLSTATE '45000' দিয়ে, যা SQLite-এর RAISE-এর সমতুল্য। Oracle-এ NEW/OLD লেখা হয় :NEW.price, :OLD.price.

৪ · RAISE — নিয়ম ভাঙলে পরিবর্তন বাতিল, আর স্টকের হিসাব

দোকানের সবচেয়ে পরিচিত নিয়ম: যত পিস স্টকে আছে, তার বেশি বিক্রি নয়; আর বিক্রি হলে স্টক কমবে। প্রথমটি যাচাই — BEFORE INSERT-এর কাজ। দ্বিতীয়টি হালনাগাদ — AFTER INSERT-এর কাজ। যাচাই ব্যর্থ হলে SQLite-এ trigger-এর ভেতর থেকে ত্রুটি তোলা হয় RAISE() দিয়ে, যা শুধু trigger-এর ভেতরেই চলে। এই এডিটরে অর্ডার 1009 (Rahim-এর pending অর্ডার)-এ দুটি নতুন লাইন যোগের চেষ্টা:

CREATE TRIGGER trg_stock_check BEFORE INSERT ON order_items
WHEN NEW.quantity > (SELECT stock FROM products WHERE product_id = NEW.product_id)
BEGIN
  SELECT RAISE(ABORT, 'not enough stock');
END;
CREATE TRIGGER trg_stock_take AFTER INSERT ON order_items
BEGIN
  UPDATE products SET stock = stock - NEW.quantity
  WHERE product_id = NEW.product_id;
END;
INSERT INTO order_items VALUES (1009, 107, 3, 4500);   -- Saree, স্টক 8
SELECT product_id, name, stock FROM products WHERE product_id IN (103, 107);
INSERT INTO order_items VALUES (1009, 103, 1, 1800);   -- Power Bank, স্টক 0

RAISE-এর চার রূপ

RAISE(ABORT, 'বার্তা') ছাড়াও আরও তিনটি রূপ আছে; পার্থক্য হলো “কতখানি ফেরানো হবে”। এক স্টেটমেন্টে অনেক সারি বদলালে পার্থক্যটি চোখে পড়ে। নিচের ডায়াগ্রামে একটি transaction: আগে একটি স্টেটমেন্ট সফল হয়েছে (Rice-এর স্টক 100 → 90), তারপর Electronics-এর চারটি পণ্যের দাম ১০% বাড়ানোর UPDATE, আর একটি trigger তৃতীয় সারিতে (Power Bank, 103) RAISE করে:

IGNORE-এর একটি বৈধ ব্যবহার: পরীক্ষার ডেটা যেন production-এ না ঢোকে। এখানে নামের শুরুতে TEST থাকলে গ্রাহক নীরবে বাদ, বাকিরা ঢোকেন:

CREATE TRIGGER trg_skip_test BEFORE INSERT ON customers
WHEN NEW.name LIKE 'TEST%'
BEGIN
  SELECT RAISE(IGNORE);
END;
INSERT INTO customers (customer_id, name, city, joined_on) VALUES
  (9,  'Sadia Islam', 'Dhaka',  '2025-10-20'),
  (10, 'TEST user',   NULL,     '2025-10-20'),
  (11, 'Rakib Hasan', 'Khulna', '2025-10-21');
SELECT customer_id, name FROM customers WHERE customer_id >= 9;

৫ · CHECK যা পারে না — অর্ডারের status শুধু সামনে চলবে

orders.status-এ CHECK আছে: মান হবে pending, shipped, delivered বা cancelled. কিন্তু ব্যবসার আসল নিয়ম আরও সূক্ষ্ম: অর্ডার pending → shipped → delivered পথে শুধু সামনে চলে; cancelled হতে পারে শুধু pending থেকে; আর delivered বা cancelled-এর পরে আর কোথাও যাওয়া নেই। কুরিয়ারে পাঠানো পার্সেল হঠাৎ “pending” হয়ে গেলে গুদামে আবার প্যাক হবে — দুবার পাঠানো, দুবার খরচ।

CHECK এটি কেন পারে না? CHECK শুধু সারির বর্তমান মান দেখে — status IN (…). “আগে কী ছিল” তার কাছে নেই। নিয়মটি আসলে একটি state machine: অবস্থাগুলোর মধ্যে কোন কোন পথ বৈধ। বৈধ পথের তালিকা লিখতে OLD আর NEW দুটিই লাগে — ঠিক যা UPDATE trigger-এর কাছে আছে। এটি একটি business rule, যা declarative constraint দিয়ে লেখা যায় না:

CREATE TRIGGER trg_status_forward
BEFORE UPDATE OF status ON orders
WHEN NOT (NEW.status = OLD.status
       OR (OLD.status = 'pending' AND NEW.status IN ('shipped', 'cancelled'))
       OR (OLD.status = 'shipped' AND NEW.status = 'delivered'))
BEGIN
  SELECT RAISE(ABORT, 'status can only move forward');
END;
UPDATE orders SET status = 'shipped'   WHERE order_id = 1006;
UPDATE orders SET status = 'delivered' WHERE order_id = 1006;
SELECT order_id, status FROM orders WHERE order_id IN (1001, 1006);
UPDATE orders SET status = 'pending'   WHERE order_id = 1001;

বাস্তবে এমন নিয়ম কোথায় লাগে: bKash বা Nagad-এর লেনদেনের অবস্থা (initiated → completed বা failed, completed থেকে আর ফেরা নেই), পরীক্ষার ফল (draft → published), ট্রেনের টিকিট (reserved → paid → cancelled/used). আরেক ধরনের নিয়ম যা CHECK পারে না: অন্য টেবিলের দিকে তাকানো — “গ্রাহকের বকেয়া ৫০,০০০ টাকার বেশি হলে নতুন অর্ডার নয়” — এখানেও trigger-এর ভেতরের subquery কাজে লাগে। (SQL standard-এ এমন নিয়মের জন্য CREATE ASSERTION আছে, কিন্তু প্রায় কোনো প্রধান DBMS এটি বাস্তবায়ন করেনি।)

৬ · Derived কলাম হালনাগাদ রাখা — আর drift-এর ঝুঁকি

অর্ডারের মোট টাকা order_items থেকে প্রতিবার হিসাব করা যায় — SUM(quantity * unit_price). কিন্তু অর্ডারের তালিকার পাতায় প্রতিটি অর্ডারের জন্য প্রতিবার যোগ করা ব্যস্ত সাইটে ভারী হতে পারে। তাই অনেকে orders-এ একটি total কলাম রাখেন — একটি সংরক্ষিত derived মান, অর্থাৎ পর্ব ৩৮-এর denormalization. প্রশ্ন: কলামটি সবসময় সঠিক থাকবে কীভাবে? Trigger দিয়ে — প্রতিটি লাইন যোগ বা মোছার সাথে সাথে:

ALTER TABLE orders ADD COLUMN total REAL NOT NULL DEFAULT 0;
UPDATE orders SET total = (SELECT COALESCE(SUM(quantity * unit_price), 0)
                           FROM order_items i WHERE i.order_id = orders.order_id);
CREATE TRIGGER trg_total_add AFTER INSERT ON order_items
BEGIN
  UPDATE orders SET total = total + NEW.quantity * NEW.unit_price
  WHERE order_id = NEW.order_id;
END;
CREATE TRIGGER trg_total_sub AFTER DELETE ON order_items
BEGIN
  UPDATE orders SET total = total - OLD.quantity * OLD.unit_price
  WHERE order_id = OLD.order_id;
END;
INSERT INTO order_items VALUES (1006, 104, 2, 650);
DELETE FROM order_items WHERE order_id = 1006 AND product_id = 110;
SELECT order_id, total FROM orders WHERE order_id IN (1001, 1006);

লক্ষ্য করুন, এখানে UPDATE-এর trigger নেই। কেউ একটি লাইনের পরিমাণ বদলালে কী হবে? এই এডিটরে উপরের কলাম, backfill আর দুটি trigger আগে থেকেই বসানো:

-- কেউ একটি লাইনের পরিমাণ বদলালেন — UPDATE-এর trigger নেই!
UPDATE order_items SET quantity = 3 WHERE order_id = 1001 AND product_id = 102;

-- মিলিয়ে দেখা: সংরক্ষিত total বনাম লাইন থেকে হিসাব
SELECT o.order_id, o.total AS stored,
       SUM(i.quantity * i.unit_price) AS actual
FROM orders o JOIN order_items i ON i.order_id = o.order_id
GROUP BY o.order_id
HAVING o.total <> SUM(i.quantity * i.unit_price);

নিরাপদ বিকল্প তিনটি, ঝুঁকি কম থেকে বেশি: (১) সংরক্ষণই না করা — একটি view-তে প্রতিবার হিসাব (পর্ব ২৪), সঠিক index থাকলে প্রায়ই যথেষ্ট দ্রুত; (২) trigger-এ বাড়ানো-কমানোর বদলে প্রতিবার পুরো যোগফল আবার গোনা — SET total = (SELECT SUM(…) …) — ধীর, কিন্তু আগের ভুল নিজে থেকে শুধরে যায়; (৩) increment trigger, তিনটি ঘটনাতেই (INSERT, UPDATE, DELETE), সাথে রাতের reconciliation.

৭ · Soft delete আর updated_at — INSTEAD OF আর AFTER UPDATE

পর্ব ১৪-এ soft delete দেখেছেন: সারি সত্যিই না মুছে একটি চিহ্ন দেওয়া। সমস্যা হলো, অ্যাপের প্রতিটি কোয়েরিতে WHERE deleted_at IS NULL মনে রাখা, আর প্রতিটি DELETE-কে UPDATE-এ বদলানো। একটি view আর একটি INSTEAD OF trigger মিলে কাজটি ডেটাবেসেই সেরে ফেলে: অ্যাপ শুধু view দেখে আর view থেকেই “মোছে”। এই এডিটরে customers-এ আগে থেকে একটি deleted_at কলাম (TEXT, শুরুতে সব NULL) যোগ করা আছে:

CREATE VIEW active_customers AS
  SELECT customer_id, name, city FROM customers WHERE deleted_at IS NULL;

CREATE TRIGGER trg_soft_delete INSTEAD OF DELETE ON active_customers
BEGIN
  UPDATE customers SET deleted_at = '2025-10-20'
  WHERE customer_id = OLD.customer_id;
END;

DELETE FROM active_customers WHERE customer_id = 5;
SELECT COUNT(*) AS active FROM active_customers;
SELECT customer_id, name, deleted_at FROM customers WHERE deleted_at IS NOT NULL;

updated_at — শেষ কবে বদলেছে

প্রায় প্রতিটি পেশাদার টেবিলে একটি updated_at কলাম থাকে: সারিটি শেষ কবে বদলেছে। এটি দিয়ে মোবাইল অ্যাপ শুধু নতুন বদলগুলো আনে, cache বাতিল হয়, ডেটা warehouse রাতে শুধু বদলানো সারি তোলে (পর্ব ৫৫)। PostgreSQL-এ BEFORE trigger NEW.updated_at বদলে দেয় (উপরের ট্যাবে দেখেছেন)। SQLite-এ NEW বদলানো যায় না, তাই প্রচলিত কৌশল AFTER UPDATE থেকে একই সারিতে আরেকটি UPDATE. এই এডিটরে products-এ updated_at কলাম যোগ করা আছে, সব সারিতে শুরুর মান '2025-01-01 00:00:00':

CREATE TRIGGER trg_touch AFTER UPDATE ON products
WHEN NEW.updated_at = OLD.updated_at      -- কেউ নিজে সময় না দিলে
BEGIN
  UPDATE products SET updated_at = datetime('now')
  WHERE product_id = NEW.product_id;
END;
UPDATE products SET stock = stock + 10 WHERE product_id = 103;
SELECT product_id, stock, updated_at > '2025-01-01 00:00:00' AS touched
FROM products WHERE product_id IN (102, 103);

৮ · Trigger-এর শিকল — cascade, recursion আর চলার ক্রম

Trigger-এর কাজ নিজেই একটি INSERT, UPDATE বা DELETE — তাই সেটি আরেকটি টেবিলের trigger জাগাতে পারে, সেটি আবার আরেকটির। একে বলে cascading trigger. ধরুন অংশ ৪-এর স্টক কমানোর trigger-এর পাশে আরেকটি নিয়ম: “কোনো পণ্যের স্টক ৫-এর নিচে নামলে পুনরায় অর্ডারের তালিকায় (reorder_alerts) তোলো।” এখন একটি সাধারণ INSERT-এর ভেতরে কী কী ঘটে:

এবার শিকলটি আসল SQLite-এ। শেষ SELECT দেখাবে, ডেটাবেসে কোন কোন trigger আছে — system catalog sqlite_schema থেকে। “লুকানো logic” খোঁজার প্রথম জায়গা এটিই:

CREATE TABLE reorder_alerts (product_id INTEGER, stock_left INTEGER);
CREATE TRIGGER trg_stock_take AFTER INSERT ON order_items
BEGIN
  UPDATE products SET stock = stock - NEW.quantity WHERE product_id = NEW.product_id;
END;
CREATE TRIGGER trg_reorder AFTER UPDATE OF stock ON products
WHEN NEW.stock < 5 AND OLD.stock >= 5
BEGIN
  INSERT INTO reorder_alerts VALUES (NEW.product_id, NEW.stock);
END;
INSERT INTO order_items VALUES (1006, 107, 4, 4500);  -- Saree: 8 → 4
INSERT INTO order_items VALUES (1006, 106, 2, 2200);  -- Panjabi: 15 → 13
SELECT * FROM reorder_alerts;
SELECT name, tbl_name FROM sqlite_schema WHERE type = 'trigger';

একই ঘটনায় একাধিক trigger — কোনটি আগে?

একই টেবিল, একই সময় (ধরুন AFTER INSERT), একাধিক trigger — চলার ক্রম DBMS-ভেদে আলাদা, আর এটি পুরোনো বাগের একটি পরিচিত উৎস। PostgreSQL নাম ধরে বর্ণানুক্রমে চালায় (তাই অনেক দল নামের শুরুতে নম্বর দেয়: t10_…, t20_…)। MySQL 5.7.2-এর আগে একই ঘটনায় একটির বেশি trigger-ই বানানো যেত না; এখন FOLLOWS/PRECEDES দিয়ে ক্রম বলা যায়। SQL Server-এ শুধু প্রথম আর শেষটি ঠিক করা যায় (sp_settriggerorder). SQLite-এর ডকুমেন্টেশন কোনো ক্রমের প্রতিশ্রুতি দেয় না; বর্তমান সংস্করণে পরীক্ষা করলে শেষে বানানোটি আগে চলে — কিন্তু প্রতিশ্রুতি নেই এমন আচরণের ওপর নির্ভর করবেন না। সবচেয়ে নিরাপদ: যে কাজগুলোর ক্রম জরুরি, সেগুলো একটি trigger-এর ভেতরে পরপর লিখুন।

৯ · Trigger, constraint না অ্যাপের কোড — বাছাই আর ঝুঁকি

Trigger শক্তিশালী বলেই অপব্যবহারও সহজ। অভিজ্ঞ দলগুলোর সাধারণ নীতি একটি সিঁড়ি: যা declarative constraint (NOT NULL, CHECK, UNIQUE, foreign key) দিয়ে লেখা যায়, সেখানেই লিখুন; যা পারে না কিন্তু ডেটার অখণ্ডতার জন্য জরুরি, তার জন্য trigger; আর যার কাজ ডেটাবেসের বাইরে, তা অ্যাপের কোডে। Constraint-কে optimizer বোঝে, ডকুমেন্টেশনে দেখা যায়, আর প্রায় খরচহীন; trigger একটি কালো বাক্স।

SMS-এর সারিটি বিশেষ করে খেয়াল করুন। trigger transaction-এর ভেতরে চলে; সেখান থেকে বাইরের কোনো সার্ভারে বার্তা পাঠালে, পরে transaction ROLLBACK হলেও বার্তা চলে গেছে — গ্রাহক এমন অর্ডারের SMS পাবেন, যা কখনো হয়নি। প্রচলিত সমাধান outbox: trigger বা অ্যাপ একই transaction-এ একটি outbox টেবিলে “পাঠাতে হবে” লেখে; COMMIT হলে তবেই একটি আলাদা প্রক্রিয়া সেটি পড়ে SMS পাঠায়।

Trigger-এর দাম — যা আগে থেকে জানা দরকার

• লুকানো logic: কোয়েরি পড়ে বোঝা যায় না, পেছনে কী ঘটছে। নতুন ডেভেলপার একটি DELETE লিখে দেখেন “০টি সারি বদলেছে”, অথচ ডেটা বদলেছে — অংশ ৭।
• Debugging কঠিন: ত্রুটি আসে স্তর ২-এর কোনো trigger থেকে, অথচ অ্যাপের log-এ শুধু মূল INSERT. বেশিরভাগ DBMS-এ trigger-এর ভেতরে breakpoint বসানোর সহজ উপায় নেই।
• বড় আমদানিতে ধীর: row-level trigger প্রতি সারিতে চলে; দশ লাখ সারির bulk load-এ দশ লাখবার audit INSERT. তাই আমদানির সময় trigger বন্ধ রাখা হয় (PostgreSQL: ALTER TABLE … DISABLE TRIGGER) — আর তখনই drift ঢোকে।
• যে পথে trigger চলে না: TRUNCATE সাধারণত DELETE trigger চালায় না; MySQL-এ foreign key-র CASCADE trigger চালায় না; SQL Server-এর BULK INSERT ডিফল্টে trigger চালায় না (FIRE_TRIGGERS লাগে)।
• ক্রম আর শিকলের চমক: অংশ ৮ — একাধিক trigger-এর ক্রম, অপ্রত্যাশিত শিকল, recursion.
• বহনযোগ্যতা কম: চারটি DBMS-এর trigger-এর syntax চার রকম (অংশ ৩-এর ট্যাব)। DBMS বদলালে সব trigger নতুন করে লিখতে হয় (পর্ব ৩১)।

DDL trigger আর event trigger

এতক্ষণের trigger ডেটার বদলে (DML) জাগে। কিছু DBMS schema-র বদলেও (DDL) trigger দেয়: SQL Server-এ DDL trigger (CREATE TRIGGER … ON DATABASE FOR DROP_TABLE), PostgreSQL-এ event trigger (CREATE EVENT TRIGGER … ON ddl_command_start), Oracle-এ BEFORE DROP ON SCHEMA. ব্যবহার: production-এ ভুল করে DROP TABLE আটকানো, কে কখন schema বদলাল তার log, migration-এর নিয়ম চাপানো (পর্ব ২৩)। SQLite আর MySQL-এ এমন কিছু নেই।

CREATE FUNCTION block_drop() RETURNS event_trigger
LANGUAGE plpgsql AS $$
BEGIN
  RAISE EXCEPTION 'DROP TABLE is blocked on this server (%)', tg_tag;
END;
$$;

CREATE EVENT TRIGGER trg_no_drop ON ddl_command_start
WHEN TAG IN ('DROP TABLE')
EXECUTE FUNCTION block_drop();

১০ · AI-এর যুগে trigger

“প্রতিটি দাম বদলের log রাখার trigger লিখে দাও” — AI কয়েক সেকেন্ডে লিখে দেয়, আর সেটি সাধারণত চলেও। বিপদ হলো, trigger-এর ভুল চুপচাপ থাকে: ভুল DBMS-এর syntax, NULL-এ বাদ পড়া বদল, statement-level DBMS-এ এক সারির অনুমান, বা অনন্ত recursion. AI-এর সাধারণ ভুলগুলো:

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

• আমার DBMS-এর syntax (SQLite-এ RAISE, MySQL-এ SIGNAL, PostgreSQL-এ function) মিলিয়েছি, নমুনা ডেটায় চালিয়েছি
• শর্ত সত্য, মিথ্যা আর NULL — তিন রকম সারি দিয়েই test করেছি
• এক স্টেটমেন্টে বহু সারি বদলে দেখেছি (বিশেষত SQL Server আর statement-level trigger-এ)
• trigger-এর আগে আর পরে প্রভাবিত টেবিলের সারির সংখ্যা মিলিয়েছি; derived কলামে reconciliation চালিয়েছি
• শিকল আর recursion ভেবে দেখেছি; নিজের টেবিল বদলালে পাহারাদার শর্ত আছে
• trigger-টির নাম, উদ্দেশ্য আর কোন টেবিলে বসানো — দলের ডকুমেন্টেশনে লিখেছি