INSERT, UPDATE আর DELETE — ডেটা বদলানো

১ · ডেটা বদলানোর তিনটি ক্রিয়া

মুদি দোকানের বাকির খাতা ভাবুন। নতুন খদ্দের এলে দোকানদার নতুন একটি লাইন লেখেন। কেউ আংশিক টাকা শোধ করলে পুরোনো অঙ্ক কেটে নতুন অঙ্ক লেখেন। কেউ পুরো শোধ করলে লাইনটিই কেটে দেন। খাতার সব কাজ এই তিনটি: লেখা, বদলানো, কাটা. SQL-এ এদের নাম INSERT, UPDATE আর DELETE.

পর্ব ১২-এ দেখেছেন, SQL-এর স্টেটমেন্টগুলো কয়েকটি দলে পড়ে। টেবিল বানানো বা বদলানো হলো DDL (পর্ব ১৩-এর CREATE TABLE). টেবিলের ভেতরের ডেটা নিয়ে কাজ হলো DML — Data Manipulation Language. SELECT ডেটা পড়ে, আর এই পর্বের তিনটি স্টেটমেন্ট ডেটা বদলায়. পড়ার ভুলে বড়জোর ভুল রিপোর্ট আসে। বদলানোর ভুলে ডেটাই নষ্ট হয়। তাই এই পর্বের অর্ধেক কথা “কীভাবে লিখবেন” নিয়ে, বাকি অর্ধেক “কীভাবে নিরাপদে লিখবেন” নিয়ে।

এই পর্বের সব লাইভ SQL চলে কোর্সের দোকানের ডেটাবেসে (db-shop, পর্ব ১১-এ যার ডিজাইন দেখেছেন)। পাঁচটি টেবিল: customers (customer_id, name, city, phone, joined_on — ৮ জন গ্রাহক), categories (category_id, name — ৪টি শ্রেণি: Electronics, Books, Clothing, Grocery), products (product_id, name, category_id, price, stock — ১০টি পণ্য, id 101–110), orders (order_id, customer_id, order_date, status — ১০টি অর্ডার, id 1001–1010) আর order_items (order_id, product_id, quantity, unit_price — ১৬টি অর্ডার-লাইন)। products-এ আছে CHECK (price > 0), CHECK (stock >= 0) আর stock-এর DEFAULT 0. প্রতিবার “চালান” চাপলে ডেটাবেস নতুন করে তৈরি হয়, তাই নির্ভয়ে মুছুন, বদলান। প্রতিটি INSERT/UPDATE/DELETE-এর পর রানার দেখায় “কয়টি সারি বদলেছে” — এই সংখ্যাটি সবসময় খেয়াল করবেন, এটিই আপনার প্রথম যাচাই।

২ · INSERT — নতুন সারি ঢোকানোর পাঁচটি রূপ

রূপ ১ — শুধু ক্রম ধরে (positional): কেন ঝুঁকিপূর্ণ

সবচেয়ে ছোট লেখা হলো কলামের নাম না দিয়ে শুধু মানগুলো দেওয়া: INSERT INTO customers VALUES (9, 'Sadia Islam', 'Barishal', NULL, '2025-10-20');. DBMS মানগুলো টেবিলের কলাম-ক্রমে বসায় — প্রথম মান customer_id-এ, দ্বিতীয়টি name-এ, এভাবে। db-shop-এর নমুনা ডেটা এভাবেই লেখা, কারণ সেটি একবারের স্ক্রিপ্ট। কিন্তু অ্যাপের কোডে এই positional INSERT একটি টাইম বোমা:

• টেবিলে কলাম যোগ হলেই ভাঙে। পরে কেউ customers-এ email কলাম যোগ করলেন (পর্ব ২৩-এর ALTER TABLE). এখন কলাম ৬টি, আপনার INSERT-এ মান ৫টি — ত্রুটি: table customers has 6 columns but 5 values were supplied.
• আরও খারাপ: নীরবে ভুল ঘরে মান। যদি কেউ টেবিলটি নতুন করে বানানোর সময় city আর phone-এর ক্রম উল্টে দেন, দুটিই TEXT — কোনো ত্রুটি আসবে না, শুধু সব নতুন গ্রাহকের শহরের ঘরে ফোন নম্বর বসবে। এমন ভুল ধরা পড়ে মাস পরে, রিপোর্টে।
• পড়া কঠিন। VALUES (9, 'Sadia', 'Barishal', NULL, …) দেখে বোঝা যায় না NULL-টি কোন কলামের।

রূপ ২ ও ৩ — কলামের নামসহ, আর একসাথে অনেক সারি

নিরাপদ রূপ হলো টেবিলের নামের পরে বন্ধনীতে কলামের তালিকা দেওয়া। তখন মানগুলো আপনার লেখা ক্রমে বসে, টেবিলের ক্রমে নয়। যে কলাম তালিকায় নেই, সেটি পায় তার DEFAULT মান, DEFAULT না থাকলে NULL — আর সেই কলামে NOT NULL থাকলে ত্রুটি। একই স্টেটমেন্টে কমা দিয়ে কয়েকটি বন্ধনী লিখলে কয়েকটি সারি একসাথে ঢোকে (multi-row VALUES; SQLite-এ 3.7.11 থেকে, ২০১২ সালে)।

-- কলামের নাম লিখে: customer_id আর phone বাদ
INSERT INTO customers (name, city, joined_on)
VALUES ('Sadia Islam', 'Barishal', '2025-10-20');

-- এক স্টেটমেন্টে দুটি সারি; stock না দিলে DEFAULT 0
INSERT INTO products (product_id, name, category_id, price) VALUES
  (111, 'Notebook (pack)', 2, 180),
  (112, 'Lungi',           3, 650);

SELECT customer_id, name, city, phone FROM customers WHERE customer_id > 7;
SELECT * FROM products WHERE product_id > 110;

রূপ ৪ ও ৫ — INSERT … SELECT আর DEFAULT VALUES

VALUES-এর জায়গায় একটি SELECT বসালে তার ফলের প্রতিটি সারি নতুন টেবিলে ঢোকে — INSERT INTO … SELECT …. পুরোনো অর্ডার archive টেবিলে সরানো, একটি রিপোর্ট-টেবিল ভরা, বা এক টেবিল থেকে অন্য টেবিলে ডেটা নেওয়ার এটিই সবচেয়ে দ্রুত পথ, কারণ ডেটা ডেটাবেসের ভেতরেই থাকে, অ্যাপে আসা-যাওয়া করে না। SELECT-এর কলাম সংখ্যা আর ক্রম INSERT-এর কলাম-তালিকার সাথে মিলতে হবে। আর যদি টেবিলের প্রতিটি কলামের DEFAULT থাকে, INSERT INTO t DEFAULT VALUES লিখে একটিও মান না দিয়ে সারি ঢোকানো যায়।

নিচের এডিটর db-shop-এর সাথে দুটি ছোট টেবিল যোগ করে: order_archive (order_id, customer_id, order_date, archived_on — শেষেরটির DEFAULT '2025-12-31') আর visit_log (visit_id, page DEFAULT 'home', hits DEFAULT 1).

-- সেপ্টেম্বর ২০২৫-এর delivered অর্ডারগুলো archive-এ কপি
INSERT INTO order_archive (order_id, customer_id, order_date)
SELECT order_id, customer_id, order_date
FROM orders
WHERE status = 'delivered' AND order_date < '2025-10-01';

SELECT * FROM order_archive;

-- কোনো মানই দিলাম না: সব কলাম DEFAULT পাবে
INSERT INTO visit_log DEFAULT VALUES;
SELECT * FROM visit_log;

৩ · স্বয়ংক্রিয় id — নতুন সারির নম্বর ফেরত পাওয়া

পর্ব ৬-এ দেখেছেন, ভালো primary key প্রায়ই একটি surrogate key — ডেটাবেস নিজে যে নম্বর দেয়। SQLite-এ INTEGER PRIMARY KEY কলামে মান না দিলে সে বসায় “এখন পর্যন্ত সবচেয়ে বড় id + 1”. MySQL-এ একই কাজ করে AUTO_INCREMENT, PostgreSQL-এ GENERATED … AS IDENTITY বা পুরোনো SERIAL (পর্ব ১৩)। এই সব ব্যবস্থাকে একসাথে বলে auto-increment.

কিন্তু একটি ব্যবহারিক সমস্যা আছে। নতুন অর্ডার ঢোকানোর পরই তার অর্ডার-লাইনগুলো ঢোকাতে হবে, আর সেখানে নতুন order_id লাগবে। নম্বরটি তো ডেটাবেস দিয়েছে — আপনি জানবেন কীভাবে? “সবচেয়ে বড় order_id কত” জিজ্ঞেস করা ভুল উত্তর: একই মুহূর্তে আরেকজন গ্রাহক অর্ডার দিলে আপনি তাঁর নম্বর পেয়ে যেতে পারেন। সঠিক পথ দুটি: last_insert_rowid() — এই সংযোগে শেষ যে সারি ঢুকেছে তার id; আর RETURNING — INSERT নিজেই নতুন সারির কলামগুলো ফেরত দেয়, যেন একটি SELECT.

-- order_id দিলাম না: SQLite নিজেই সবচেয়ে বড় id + 1 বসাবে
INSERT INTO orders (customer_id, order_date, status)
VALUES (4, '2025-10-20', 'pending');
SELECT last_insert_rowid() AS new_id;

-- RETURNING: INSERT নিজেই নতুন সারি ফেরত দেয়
INSERT INTO orders (customer_id, order_date, status)
VALUES (5, '2025-10-21', 'pending')
RETURNING order_id, customer_id, status;

অন্য DBMS-এ একই কাজ (চালানো যায় না, শুধু তুলনার জন্য):

INSERT INTO orders (customer_id, order_date, status)
VALUES (4, '2025-10-20', 'pending')
RETURNING order_id;            -- PostgreSQL 8.2 থেকে; UPDATE/DELETE-এও চলে

INSERT INTO orders (customer_id, order_date, status)
VALUES (4, '2025-10-20', 'pending');
SELECT LAST_INSERT_ID();       -- এই সংযোগের শেষ AUTO_INCREMENT মান
-- MySQL-এ RETURNING নেই (MariaDB-তে INSERT/DELETE … RETURNING আছে)
-- SQL Server: INSERT … OUTPUT inserted.order_id VALUES (…)
-- Oracle: INSERT … RETURNING order_id INTO :new_id

একটি পূর্ণ অর্ডার — কয়েকটি স্টেটমেন্ট, একটি কাজ

বাস্তবে “অর্ডার দেওয়া” একটি স্টেটমেন্ট নয়: orders-এ একটি সারি, order_items-এ প্রতিটি পণ্যের একটি সারি, আর products-এ স্টক কমানো। মাঝপথে বিদ্যুৎ গেলে (লোডশেডিং!) অর্ধেক অর্ডার থেকে যেতে পারে — অর্ডার আছে কিন্তু লাইন নেই, বা স্টক কমেছে কিন্তু অর্ডার নেই। তাই পুরোটি BEGIN আর COMMIT-এর মাঝে রাখা হয়: হয় সব পাকা হবে, নয়তো কিছুই না। Transaction-এর পুরো তত্ত্ব পর্ব ৪৪-এ; এখানে শুধু ব্যবহার দেখুন। অ্যাপে 1011 সংখ্যাটি আসত RETURNING থেকে; এখানে পড়ার সুবিধার জন্য সরাসরি লেখা।

-- Nusrat (4) কিনছেন: ২টি DSA Book (104), ১টি Rice 5kg (108)
BEGIN;
INSERT INTO orders (order_id, customer_id, order_date, status)
VALUES (1011, 4, '2025-10-20', 'pending');
INSERT INTO order_items (order_id, product_id, quantity, unit_price) VALUES
  (1011, 104, 2, 650),
  (1011, 108, 1, 420);
UPDATE products SET stock = stock - 2 WHERE product_id = 104;
UPDATE products SET stock = stock - 1 WHERE product_id = 108;
COMMIT;

SELECT * FROM order_items WHERE order_id = 1011;
SELECT product_id, name, stock FROM products WHERE product_id IN (104, 108);

৪ · UPDATE — WHERE দিয়ে ঠিক সারিগুলো বদলানো

UPDATE-এর গঠন তিন অংশের: কোন টেবিল (UPDATE products), কোন কলামে কী মান (SET stock = stock + 25), আর কোন সারিতে (WHERE product_id = 103). WHERE যে সারিগুলোর জন্য সত্য, শুধু সেগুলো বদলায়। WHERE-এ primary key দিলে একটি সারি; অন্য শর্ত দিলে যতগুলো মেলে, সবগুলো। SET-এ নতুন মান সরাসরি লেখা যায়, আবার পুরোনো মান থেকে হিসাব করেও লেখা যায় — price = price * 1.10 মানে “এই সারির বর্তমান দামের ১.১ গুণ”। নিচের ডায়াগ্রামে দেখুন DBMS ধাপে ধাপে কী করে:

এবার নিজে চালান। প্রথম UPDATE একটি সারির (primary key দিয়ে), দ্বিতীয়টি একটি শ্রেণির সব সারির:

-- নতুন চালান এল: Power Bank (103)-এ ২৫টি
UPDATE products SET stock = stock + 25 WHERE product_id = 103;

-- Books শ্রেণির সব বইয়ের দাম ১০% বাড়ল
UPDATE products
SET price = ROUND(price * 1.10, 2)
WHERE category_id = (SELECT category_id FROM categories WHERE name = 'Books');

SELECT product_id, name, price, stock FROM products
WHERE product_id IN (103, 104, 105);

অন্য টেবিল থেকে মান এনে UPDATE

কখনো নতুন মানটি অন্য টেবিলে থাকে। ধরুন অর্ডার 1009 (Rahim Uddin-এর, pending) বাতিল হলো: তাতে ১টি Mobile Phone (101) আর ১টি Smart Watch (110) ছিল, সেগুলো স্টকে ফেরত যাবে। প্রতিটি পণ্যের কতটি ফেরত যাবে, তা লেখা order_items-এ। দুটি পথ আছে। পুরোনো, সব DBMS-এ চলে এমন পথ হলো SET-এ একটি correlated subquery: SET stock = stock + (SELECT quantity FROM order_items WHERE order_id = 1009 AND product_id = products.product_id), সাথে WHERE-এ product_id IN (SELECT product_id FROM order_items WHERE order_id = 1009) — WHERE ভুলে গেলে অন্য সব পণ্যে subquery-র ফল NULL হতো, আর stock-এ NULL বসানোর চেষ্টা NOT NULL-এ আটকে পুরো স্টেটমেন্ট ব্যর্থ হতো। নতুন, পরিষ্কার পথ হলো UPDATE … FROM: অন্য টেবিলটিকে join-এর মতো জুড়ে দেওয়া। এটি PostgreSQL-এ বহুদিনের, আর SQLite-এ এসেছে 3.33.0 (২০২০) থেকে; MySQL-এ লেখা হয় UPDATE products JOIN order_items … SET ….

-- অর্ডার 1009 (pending) বাতিল: পণ্যগুলো স্টকে ফেরত
BEGIN;
UPDATE products
SET stock = products.stock + oi.quantity
FROM order_items AS oi
WHERE oi.product_id = products.product_id
  AND oi.order_id = 1009;
UPDATE orders SET status = 'cancelled' WHERE order_id = 1009;
COMMIT;

SELECT product_id, name, stock FROM products WHERE product_id IN (101, 110);
SELECT * FROM orders WHERE order_id = 1009;

৫ · WHERE ভুলে গেলে — সবচেয়ে বড় বিপদ আর নিরাপদ অভ্যাস

SQL-এ WHERE ঐচ্ছিক। UPDATE products SET price = 100; সম্পূর্ণ বৈধ স্টেটমেন্ট: সব পণ্যের দাম ১০০ টাকা। DELETE FROM order_items;-ও বৈধ: সব অর্ডার-লাইন উধাও। DBMS কোনো প্রশ্ন করে না, কারণ SQL সারির সেট নিয়ে কাজ করে, আর শর্তহীন সেট মানে পুরো টেবিল। ডেটাবেস নিয়ে যাঁরা কাজ করেন, তাঁদের প্রায় সবার এই ভুলের অন্তত একটি গল্প আছে — প্রায়ই একটি লম্বা স্টেটমেন্ট লিখে শেষ লাইনের WHERE-টি সিলেক্ট না করেই “চালান” চাপা।

রক্ষাকবচ হলো transaction. Autocommit অবস্থায় (ডিফল্টে) প্রতিটি স্টেটমেন্ট চলার সাথে সাথেই পাকা হয়ে যায়। কিন্তু আগে BEGIN লিখলে পরের পরিবর্তনগুলো “খসড়া” থাকে, যতক্ষণ না আপনি COMMIT (পাকা) বা ROLLBACK (সব বাতিল) বলেন। নিচে দেখুন একটি ভুল DELETE কীভাবে ফেরানো যায়:

BEGIN;
DELETE FROM order_items;            -- ভুল! WHERE ভুলে গেছি
SELECT COUNT(*) AS lines_left FROM order_items;
ROLLBACK;                           -- সব ফিরিয়ে নিন
SELECT COUNT(*) AS lines_left FROM order_items;

নিরাপদ অভ্যাসের তালিকা

1. আগে SELECT, পরে বদল। DELETE FROM orders WHERE status = 'cancelled' লেখার আগে চালান SELECT * FROM orders WHERE status = 'cancelled'. যে সারিগুলো দেখলেন, ঠিক সেগুলোই বদলাবে। তারপর শুধু প্রথম শব্দটি বদলান — WHERE একই থাকবে।
2. সংখ্যা মিলিয়ে নিন। SELECT-এ ১টি সারি এসেছিল, UPDATE বলছে “৩৪০টি সারি বদলেছে”? তাহলে থামুন, ROLLBACK.
3. হাতে চালানো প্রতিটি বদল BEGIN দিয়ে শুরু। যাচাই করে তবেই COMMIT.
4. সম্ভব হলে primary key দিয়ে WHERE. নাম বা শহর দিয়ে নয় — “Rahim” নামে কতজন আছেন, কে জানে।
5. Production ডেটাবেসে সরাসরি না লেখা। আগে একটি কপিতে চালান; নিয়মিত backup রাখুন আর তা থেকে ফেরানো পরীক্ষা করুন।

MySQL-এ এর জন্য একটি বিল্ট-ইন সুরক্ষাও আছে: safe-updates mode. চালু থাকলে key কলামের শর্ত বা LIMIT ছাড়া UPDATE/DELETE সে চালায়ই না। MySQL Workbench-এ এটি ডিফল্টে চালু থাকে, আর mysql কমান্ড-লাইন ক্লায়েন্টে --safe-updates দিয়ে চালু করা যায় — যার একটি মজার বিকল্প নামও আছে: --i-am-a-dummy.

SET SQL_SAFE_UPDATES = 1;
DELETE FROM order_items;
-- ERROR 1175 (HY000): You are using safe update mode and you tried to
-- update a table without a WHERE that uses a KEY column.
DELETE FROM order_items WHERE order_id = 1004;   -- key কলামে শর্ত: চলবে

৬ · DELETE, TRUNCATE আর DROP — তিন রকম “মোছা”

তিনটি স্টেটমেন্টই কিছু একটা মোছে, কিন্তু মাত্রা আলাদা। খাতার উপমায়: DELETE হলো কিছু লাইন কেটে দেওয়া, TRUNCATE হলো খাতার সব লেখা পাতা ছিঁড়ে ফেলে মলাট রেখে দেওয়া, আর DROP TABLE হলো পুরো খাতাটাই ফেলে দেওয়া — মলাট, ঘরের দাগ, সব।

SQLite-এ TRUNCATE নামে কোনো স্টেটমেন্ট নেই। তবে WHERE ছাড়া DELETE FROM t-কে সে নিজেই দ্রুত পথে চালায় (“truncate optimization”), যদি টেবিলে trigger না থাকে আর foreign key-র কারণে সারি ধরে যাচাই না লাগে। TRUNCATE-এর আসল ব্যবহার হলো staging টেবিল — প্রতি রাতে বাইরের ফাইল থেকে ডেটা এনে রাখার অস্থায়ী টেবিল — খালি করা, যেখানে লাখ লাখ সারি এক এক করে log করার কোনো মানে নেই।

TRUNCATE TABLE staging_sales;                       -- সব সারি, খুব দ্রুত
TRUNCATE TABLE staging_sales RESTART IDENTITY;      -- id কাউন্টারও 1 থেকে
TRUNCATE TABLE orders CASCADE;   -- orders-কে FK দিয়ে ধরে রাখা টেবিলও খালি — সাবধান!
DROP TABLE IF EXISTS staging_sales;                 -- টেবিলটিই নেই হয়ে যায়

৭ · Constraint ভাঙলে — statement atomicity আর foreign key

পর্ব ৬-এ দেখেছেন, INSERT বা UPDATE কোনো constraint ভাঙলে DBMS পুরো স্টেটমেন্ট ফিরিয়ে দেয়। এখানে “পুরো” শব্দটি গুরুত্বপূর্ণ। ১০০ সারির একটি INSERT-এর ১০০তম সারি CHECK ভাঙলে আগের ৯৯টিও ঢোকে না; ৫০টি সারি বদলানো একটি UPDATE-এর ৩০তম সারিতে সমস্যা হলে আগের ২৯টির বদলও ফিরিয়ে নেওয়া হয়। একে বলে statement atomicity — প্রতিটি স্টেটমেন্ট নিজেই একটি ছোট, অবিভাজ্য কাজ (পর্ব ৪৪-এর atomicity-র ক্ষুদ্র রূপ)। নিচে তৃতীয় সারির দাম 0, যা CHECK (price > 0) ভাঙে:

SELECT COUNT(*) AS before FROM products;

-- তিনটি সারি: প্রথম দুটি ঠিক, তৃতীয়টির দাম 0
INSERT INTO products (product_id, name, category_id, price, stock) VALUES
  (111, 'Notebook (pack)', 2, 180, 50),
  (112, 'Lungi',           3, 650, 20),
  (113, 'Free Sample',     4,   0, 10);

import sqlite3

con = sqlite3.connect(":memory:")
con.execute("CREATE TABLE products (product_id INTEGER PRIMARY KEY,"
            " name TEXT NOT NULL, price REAL NOT NULL CHECK (price > 0))")
con.execute("INSERT INTO products VALUES (101, 'Mobile Phone', 15000)")
con.commit()

rows = [(111, "Notebook (pack)", 180), (112, "Lungi", 650),
        (113, "Free Sample", 0)]          # last row breaks CHECK
try:
    con.execute("INSERT INTO products VALUES (?, ?, ?), (?, ?, ?), (?, ?, ?)",
                [v for r in rows for v in r])
except sqlite3.IntegrityError as e:
    print("error:", e)

count = con.execute("SELECT COUNT(*) FROM products").fetchone()[0]
print("rows after failed INSERT:", count)    # still 1

cur = con.execute("INSERT INTO products (name, price) VALUES (?, ?)", ("Lungi", 650))
print("new id from cursor.lastrowid:", cur.lastrowid)
con.commit()

Foreign key আর DELETE — RESTRICT বনাম CASCADE ফিরে দেখা

DELETE-এর সবচেয়ে সাধারণ ত্রুটি আসে foreign key থেকে। order_items-এর product_id → products. যে পণ্য কোনো অর্ডারে আছে, সেটি মুছলে অর্ডার-লাইনগুলো “অনাথ” হবে, তাই ডিফল্ট নিয়ম (NO ACTION) মোছা আটকায়। Power Bank (103) কোনো অর্ডারে নেই, DSA Book (104) আছে দুটি অর্ডারে (1002 আর 1005):

-- Power Bank (103) কোনো অর্ডারে নেই: মুছবে
DELETE FROM products WHERE product_id = 103;

-- DSA Book (104) দুটি অর্ডারে আছে: মুছবে না
DELETE FROM products WHERE product_id = 104;

৮ · UPSERT — “থাকলে বদলানো, না থাকলে ঢোকানো”

গুদামে মাসিক স্টক-গণনা হলো। কর্মীরা একটি তালিকা দিলেন: কোন পণ্য কতটি এল। কিছু পণ্য আগেই products-এ আছে (স্টক বাড়াতে হবে), কিছু একদম নতুন (ঢোকাতে হবে)। সহজ চিন্তা: “আগে SELECT করে দেখি আছে কি না, তারপর INSERT বা UPDATE”. কিন্তু SELECT আর INSERT-এর মাঝের মুহূর্তে আরেকটি প্রক্রিয়া একই পণ্য ঢুকিয়ে দিলে আপনার INSERT duplicate key-তে ব্যর্থ হবে, বা দুজনেই UPDATE ভেবে একজনের যোগ হারাবে। সমাধান হলো একটি স্টেটমেন্টে দুটি কাজ — UPSERT (UPdate + inSERT). SQLite (3.24.0, ২০১৮ থেকে) আর PostgreSQL (9.5, ২০১৬ থেকে)-এ লেখা হয় INSERT … ON CONFLICT (কলাম) DO UPDATE SET … বা DO NOTHING.

-- স্টক-গণনার তালিকা: আছে এমন পণ্যে যোগ, নতুন পণ্য ঢোকাও
INSERT INTO products (product_id, name, category_id, price, stock)
VALUES (102, 'Headphone', 1, 1200, 15),
       (111, 'Notebook (pack)', 2, 180, 50)
ON CONFLICT (product_id) DO UPDATE
SET stock = products.stock + excluded.stock;

-- শ্রেণি আগে থাকলে কিছুই কোরো না
INSERT INTO categories (name) VALUES ('Books'), ('Toys')
ON CONFLICT (name) DO NOTHING;

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

অন্য DBMS-এ UPSERT আর MERGE

INSERT INTO products (product_id, name, category_id, price, stock)
VALUES (102, 'Headphone', 1, 1200, 15)
ON CONFLICT (product_id) DO UPDATE
SET stock = products.stock + EXCLUDED.stock
RETURNING product_id, stock;      -- SQLite-এর মতোই, সাথে RETURNING

INSERT INTO products (product_id, name, category_id, price, stock)
VALUES (102, 'Headphone', 1, 1200, 15) AS new
ON DUPLICATE KEY UPDATE stock = products.stock + new.stock;
-- পুরোনো লেখা: stock = stock + VALUES(stock) (8.0.20 থেকে deprecated)
-- যেকোনো PRIMARY KEY বা UNIQUE সংঘাতেই চলে — কলাম বেছে দেওয়া যায় না
-- কিছু না করতে: INSERT IGNORE (তবে এটি অন্য ত্রুটিও চেপে যায়)

MERGE INTO products AS p
USING stock_count AS s            -- আরেকটি টেবিল বা কোয়েরি
   ON p.product_id = s.product_id
WHEN MATCHED THEN
     UPDATE SET stock = p.stock + s.qty
WHEN NOT MATCHED THEN
     INSERT (product_id, name, category_id, price, stock)
     VALUES (s.product_id, s.name, s.category_id, s.price, s.qty);

MERGE এসেছে SQL:2003 standard-এ। এটি পুরো একটি “উৎস” টেবিলকে লক্ষ্য টেবিলের সাথে মিলিয়ে প্রতিটি সারির জন্য UPDATE, INSERT বা (WHEN MATCHED … THEN DELETE দিয়ে) DELETE চালায় — ডেটা warehouse-এ রাতের লোডে খুব প্রচলিত (পর্ব ৫৫)। Oracle (9i থেকে) আর SQL Server (2008 থেকে)-এ বহুদিন আছে, PostgreSQL-এ এসেছে 15 (২০২২) থেকে; SQLite আর MySQL-এ নেই। একটি সতর্কতা: MERGE-এর মিল খোঁজা সাধারণ join-এর মতো, তাই একসাথে দুটি সেশন চালালে দুজনেই “মিল নেই” দেখে INSERT করে duplicate key ত্রুটি পেতে পারে। PostgreSQL-এর ডকুমেন্টেশনও একসাথে চলা INSERT-এর ঝুঁকি থাকলে বিকল্প হিসেবে ON CONFLICT বিবেচনা করতে বলে।

৯ · Soft delete, hard delete আর বিপুল ডেটা লোড

এ পর্যন্ত DELETE মানে সারিটি সত্যিই চলে যাওয়া — একে বলে hard delete. অনেক সিস্টেমে কিন্তু সারি প্রায় কখনো মোছা হয় না। গ্রাহক অ্যাকাউন্ট বন্ধ করলেন, পণ্য বিক্রি বন্ধ হলো, কর্মী চাকরি ছাড়লেন — তবু তাঁদের পুরোনো অর্ডার, বিল, হাজিরার রেকর্ড অর্থপূর্ণ, আর হিসাব-নিরীক্ষার জন্য প্রায়ই রাখা বাধ্যতামূলক। তখন মোছার বদলে একটি চিহ্ন দেওয়া হয়: soft delete. NID ডেটাবেসের কথা ভাবুন — একজন নাগরিক মারা গেলে তাঁর রেকর্ড মুছে ফেলা হয় না, অবস্থা বদলানো হয়; পুরোনো দলিল আর উত্তরাধিকারের জন্য রেকর্ডটি দরকার।

ALTER TABLE customers ADD COLUMN deleted_at TEXT;        -- NULL = সক্রিয়

-- “মোছা” আসলে একটি UPDATE
UPDATE customers SET deleted_at = '2025-10-20' WHERE customer_id = 5;

-- অ্যাপ সবসময় সক্রিয়দের দেখে — একটি view সহজ করে (পর্ব ২৪)
CREATE VIEW active_customers AS
  SELECT * FROM customers WHERE deleted_at IS NULL;

-- সক্রিয়দের মধ্যেই ফোন নম্বর অনন্য: partial unique index
CREATE UNIQUE INDEX one_active_phone ON customers(phone)
  WHERE deleted_at IS NULL;

বিপুল ডেটা একবারে লোড করা

একটি CSV ফাইলে দশ লাখ বিক্রির রেকর্ড এল। দশ লাখ আলাদা INSERT চালানো সম্ভব, কিন্তু ধীর: প্রতিটি স্টেটমেন্ট আলাদা করে parse হয়, আর autocommit-এ প্রতিটি আলাদা transaction — প্রতিবার ডিস্কে পাকা করে লেখা (fsync). প্রথম উন্নতি সহজ: সব INSERT একটি BEGIN … COMMIT-এর ভেতরে, আর multi-row VALUES. আরও দ্রুত হলো প্রতিটি DBMS-এর নিজস্ব bulk load ব্যবস্থা, যা ফাইল সরাসরি টেবিলে ঢালে। কোনোটিই এই পাতায় চালানো যায় না:

COPY sales (sale_id, product_id, qty, sold_on)
FROM '/data/sales.csv' WITH (FORMAT csv, HEADER true);   -- সার্ভারের ফাইল
-- psql থেকে নিজের কম্পিউটারের ফাইল: \copy sales FROM 'sales.csv' CSV HEADER

LOAD DATA LOCAL INFILE 'sales.csv' INTO TABLE sales
FIELDS TERMINATED BY ',' IGNORE 1 LINES;   -- সার্ভার ও ক্লায়েন্টে local_infile চালু থাকতে হয়

sqlite3 shop.db
sqlite> .mode csv
sqlite> .import --skip 1 sales.csv sales

বড় লোডের আগে অভিজ্ঞরা তিনটি কাজ করেন: আগে একটি staging টেবিলে লোড করে সেখানে duplicate আর ভুল মান খোঁজেন, তারপর INSERT … SELECT বা UPSERT দিয়ে মূল টেবিলে আনেন; দরকারে বড় লোডের সময় কিছু index পরে বানান (প্রতিটি সারিতে index হালনাগাদ ব্যয়বহুল, পর্ব ৪০); আর লোডের পর সারি গুনে ফাইলের লাইনের সংখ্যার সাথে মেলান।

১০ · AI-এর যুগে ডেটা বদলানো

AI-কে “দাম ১০% বাড়িয়ে দাও” বা “পুরোনো অর্ডার মুছে দাও” বললে সে সাথে সাথে একটি UPDATE বা DELETE লিখে দেয়, আর বেশিরভাগ সময় সেটি চলে. বিপদ এখানেই: SELECT ভুল হলে ভুল রিপোর্ট আসে, কিন্তু UPDATE বা DELETE ভুল হলে ডেটাই বদলে যায়। AI প্রায়ই যা ভুল করে:

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

• প্রতিটি কলাম আর টেবিলের নাম আসল schema-র সাথে মিলিয়েছি
• একই WHERE দিয়ে SELECT চালিয়ে সারিগুলো দেখেছি আর গুনেছি
• NULL, duplicate নাম আর শূন্য সারির মতো কিনারার ঘটনায় কী হবে ভেবেছি
• BEGIN দিয়ে শুরু করেছি; “কয়টি সারি বদলেছে” আশার সাথে মিললে তবেই COMMIT
• প্রথমে একটি কপি বা test ডেটাবেসে চালিয়েছি; production-এর সাম্প্রতিক backup আছে
• বড় টেবিলে WHERE-এর কলামে index আছে কি না দেখেছি (EXPLAIN, পর্ব ৪১) — নইলে দীর্ঘ lock