CREATE TABLE — ডেটা টাইপ আর constraint

১ · CREATE TABLE — একটি টেবিলের জন্মসনদ

মুদি দোকানের নতুন খাতা কেনার পর দোকানদার প্রথম পাতায় কলাম টানেন: তারিখ, ক্রেতার নাম, পণ্য, দাম। কলামের মাথায় যা লেখা হয়, পুরো খাতা সেভাবেই চলে। দামের ঘরে কেউ “আগামী সপ্তাহে দেব” লিখলে হিসাব মেলে না। ডেটাবেসে এই প্রথম পাতাটিই CREATE TABLE. পার্থক্য একটাই: খাতা ভুল লেখা আটকাতে পারে না, ডেটাবেস পারে।

পর্ব ১২-এ SQL-এর সাথে পরিচয় হয়েছে। CREATE TABLE হলো DDL (Data Definition Language) — ডেটা নয়, ডেটার কাঠামো বানায়। পর্ব ১০-এ ER ডায়াগ্রাম থেকে যে টেবিলগুলো বের করেছিলেন, এখানে সেগুলো আসল SQL হবে। সাধারণ রূপ:

CREATE TABLE table_name (
  column_1  data_type  [column constraint ...],
  column_2  data_type  [column constraint ...],
  ...
  [table constraint, ...]
);

প্রতিটি কলামের তিনটি অংশ: নাম, টাইপ, আর ঐচ্ছিক নিয়ম। কলামগুলোর মাঝে কমা, শেষ কলাম বা শেষ নিয়মের পরে কমা নয় — নতুনদের সবচেয়ে সাধারণ syntax ত্রুটি এটিই। এবার db-shop-এর customers টেবিলটি শূন্য থেকে বানাই। এই এডিটরে কোনো নমুনা ডেটা নেই, ডেটাবেস একদম খালি:

-- db-shop-এর customers টেবিল, একদম শূন্য থেকে
CREATE TABLE customers (
  customer_id INTEGER PRIMARY KEY,
  name        TEXT NOT NULL,
  city        TEXT,
  phone       TEXT UNIQUE,
  joined_on   TEXT NOT NULL      -- 'YYYY-MM-DD'
);
INSERT INTO customers VALUES
 (1, 'Rahim Uddin',  'Dhaka',      '01711000001', '2025-01-15'),
 (2, 'Karima Begum', 'Chattogram', '01811000002', '2025-02-03');
SELECT * FROM customers;
PRAGMA table_info(customers);

নাম রাখার নিয়ম

• ছোট হাতের অক্ষর আর আন্ডারস্কোর (snake_case): order_items, joined_on. PostgreSQL উদ্ধৃতিচিহ্ন ছাড়া নামকে ছোট হাতের করে নেয়, Oracle বড় হাতের। MySQL-এ টেবিলের নাম Linux সার্ভারে সাধারণত case-sensitive, Windows-এ নয় — মিশ্র অক্ষর তাই ঝামেলা আনে।
• সংরক্ষিত শব্দ এড়ান: order, user, group, select SQL-এর নিজের শব্দ। টেবিলের নাম order দিলে প্রতিবার "order" লিখতে হবে। এজন্যই db-shop-এ orders.
• বাংলা নাম সম্ভব, কিন্তু নয়: "গ্রাহক" উদ্ধৃতিচিহ্নে দিলে অনেক DBMS মেনে নেয়, কিন্তু টুল, ORM আর সহকর্মীর কিবোর্ড ঝামেলা করবে। ডেটা বাংলায় রাখুন, নাম ইংরেজিতে।
• দৈর্ঘ্যের সীমা আছে: PostgreSQL-এ ৬৩ বাইট, MySQL-এ ৬৪ অক্ষর, Oracle 12.2-এর আগে মাত্র ৩০ বাইট।

IF NOT EXISTS, DROP TABLE আর অস্থায়ী টেবিল

একই নামের টেবিল আগে থাকলে CREATE TABLE ত্রুটি দেয় (table customers already exists). Setup স্ক্রিপ্ট বারবার চালাতে হলে লিখুন CREATE TABLE IF NOT EXISTS — টেবিল থাকলে চুপচাপ কিছুই করবে না। সাবধান: পুরোনো টেবিলের কাঠামো আলাদা হলেও সে তা যাচাই করে না। উল্টো কাজ DROP TABLE: টেবিল, তার সব ডেটা, index আর trigger একসাথে মুছে দেয়, আর সাধারণত ব্যাকআপ ছাড়া তা ফেরানো যায় না। ব্যতিক্রম: PostgreSQL, SQLite আর SQL Server-এ DROP একটি transaction-এর ভেতরে থাকলে ROLLBACK করা যায়; MySQL-এ DROP সঙ্গে সঙ্গে স্থায়ী হয়। DROP TABLE IF EXISTS না-থাকা টেবিলে ত্রুটি দেয় না। আর অস্থায়ী টেবিল (CREATE TEMP TABLE) শুধু এই সংযোগের জন্য বাঁচে, সংযোগ বন্ধ হলেই উধাও:

-- customers আগেই আছে: IF NOT EXISTS থাকায় ত্রুটি নয়, কিছুই হয় না
CREATE TABLE IF NOT EXISTS customers (x INTEGER);
SELECT COUNT(*) AS n FROM customers;

-- নেই এমন টেবিল মুছতে চাইলেও ত্রুটি নয়
DROP TABLE IF EXISTS old_customers;

-- শুধু এই সংযোগের জন্য: একটি কেনাকাটার ঝুড়ি
CREATE TEMP TABLE cart (product_id INTEGER, qty INTEGER);
INSERT INTO cart VALUES (101, 1), (108, 3);
SELECT * FROM cart;
SELECT type, name FROM sqlite_temp_schema;

২ · সংখ্যার টাইপ — পূর্ণসংখ্যা, টাকা আর floating-এর ফাঁদ

ডেটা টাইপ হলো কলামের domain-এর মোটা দাগের সীমানা (পর্ব ৫): কোন ধরনের মান আসতে পারে, কত বড়, কত জায়গা লাগবে, কীভাবে তুলনা ও সাজানো হবে। “10” আর “9” লেখা হিসেবে সাজালে “10” আগে আসে (‘1’ < ‘9’), সংখ্যা হিসেবে পরে — তাই টাইপ শুধু জায়গার প্রশ্ন নয়, অর্থেরও।

পূর্ণসংখ্যা: SMALLINT, INTEGER, BIGINT

৪ বাইটের INTEGER-এর সর্বোচ্চ মান 2,147,483,647. শুনতে বিশাল, কিন্তু একটি জনপ্রিয় অ্যাপের লেনদেন বা লগ-টেবিলের id কয়েক বছরে এটি পার হতে পারে — তখন নতুন সারি ঢোকা বন্ধ, আর কোটি সারির টেবিলে BIGINT-এ বদলানো ঘণ্টার কাজ। তাই বড় হতে পারে এমন id শুরু থেকেই BIGINT. SQLite-এ এই ভাগ নেই: তার INTEGER মানের আকার দেখে ১ থেকে ৮ বাইটে জমা হয়।

টাকা: DECIMAL / NUMERIC(p, s)

DECIMAL(p, s) (একই জিনিস NUMERIC) একটি নির্দিষ্ট দশমিকের সংখ্যা: মোট p অঙ্ক, তার মধ্যে s অঙ্ক দশমিকের পরে। DECIMAL(12,2) রাখে 9,999,999,999.99 পর্যন্ত, আর প্রতিটি পয়সা নিখুঁতভাবে। কেন এটি জরুরি, দেখুন floating point (REAL, DOUBLE PRECISION, FLOAT) কী করে। এগুলো দশমিক নয়, দুই-ভিত্তিক ভগ্নাংশে সংখ্যা রাখে, আর 0.1 দুই-ভিত্তিতে ঠিক লেখা যায় না — যেমন ১/৩ দশমিকে 0.333… হয়ে চলতেই থাকে। SQLite-এ SELECT 0.1 + 0.2, 0.1 + 0.2 = 0.3; চালালে আসে:

0.1 + 0.2             0.1 + 0.2 = 0.3
0.30000000000000004   0

অর্থাৎ ডেটাবেসের চোখে 0.1 + 0.2 আর 0.3 সমান নয়। লাখো লেনদেনে এই ক্ষুদ্র ভুল জমে হিসাব মেলে না, আর WHERE amount = 0.3 সারি খুঁজে পায় না। নিয়ম তাই সোজা:

SQLite-এ সত্যিকারের DECIMAL নেই (অংশ ৪-এ দেখবেন DECIMAL(10,2) লিখলেও মান REAL হিসেবে জমা হতে পারে), তাই SQLite-এ টাকা রাখার প্রচলিত উপায় পয়সায় INTEGER. db-shop সরলতার জন্য দাম REAL-এ রেখেছে, কারণ সব দাম পূর্ণ টাকা — বাস্তব অ্যাপে তা করবেন না।

৩ · লেখা, তারিখ আর বাকি টাইপ — পাঁচ DBMS পাশাপাশি

CHAR(n), VARCHAR(n) আর TEXT

• CHAR(n) — ঠিক n অক্ষর; ছোট মান দিলে ডান দিকে ফাঁকা জায়গা বসে। CHAR(2)-এ দেশের কোড 'BD' মানায়, নামের জন্য নয়।
• VARCHAR(n) — সর্বোচ্চ n অক্ষর, যতটুকু দরকার ততটুকু জায়গা। সীমা নিজেই একটি নিয়ম: VARCHAR(11)-এ ১২ অক্ষরের ফোন নম্বর ঢুকবে না (PostgreSQL ত্রুটি দেয়; MySQL strict mode-এ ত্রুটি, পুরোনো non-strict mode-এ চুপচাপ কেটে ফেলত)।
• TEXT — দৈর্ঘ্যের সীমাহীন (বা খুব বড় সীমার) লেখা। PostgreSQL-এ TEXT আর VARCHAR(n)-এর গতি একই; পার্থক্য শুধু সীমা যাচাইয়ে। SQLite VARCHAR(50) লিখলে মেনে নেয়, কিন্তু ৫০-এর সীমা যাচাই করে না।

বাংলা লেখা — Unicode আর utf8mb4

বাংলা অক্ষর Unicode-এর U+0980–U+09FF অংশে। আজকের প্রচলিত এনকোডিং UTF-8-এ প্রতিটি বাংলা অক্ষর (কার-চিহ্নসহ প্রতিটি code point) ৩ বাইট, ইংরেজি অক্ষর ১ বাইট, আর অনেক emoji ৪ বাইট। SQLite-এ SELECT length('বাংলাদেশ'), length(CAST('বাংলাদেশ' AS BLOB)); দেয় 8 | 24 — ৮টি code point (ব, া, ং, ল, া, দ, ে, শ), ২৪ বাইট। “n অক্ষর” তাই DBMS ভেদে আলাদা জিনিস:

• MySQL: পুরোনো utf8 আসলে utf8mb3 — প্রতি অক্ষরে সর্বোচ্চ ৩ বাইট। বাংলা চলে, কিন্তু ৪ বাইটের emoji (😀) ঢোকাতে গেলে ত্রুটি বা প্রশ্নবোধক চিহ্ন। সমাধান utf8mb4, যা MySQL 8.0 থেকে ডিফল্ট। পুরোনো সার্ভারে টেবিল বানাতে লিখুন ... ) CHARACTER SET utf8mb4;
• Oracle: VARCHAR2(10) ডিফল্টভাবে প্রায়ই ১০ বাইট বোঝায় (সেটিং-নির্ভর) — মাত্র ৩টি বাংলা অক্ষর! VARCHAR2(10 CHAR) লিখলে ১০ অক্ষর।
• SQL Server: বাংলার জন্য ঐতিহ্যগতভাবে NVARCHAR, আর লেখার আগে N: N'রহিম'. N ছাড়া লিখলে বাংলা প্রশ্নবোধক চিহ্নে বদলে যেতে পারে।
• PostgreSQL আর SQLite: ডেটাবেস UTF-8 হলে VARCHAR(n) n অক্ষর গোনে, বাড়তি কিছু লাগে না।

তারিখ আর সময়

DATE (2025-10-20), TIME (14:30:00), আর তারিখ-সময় একসাথে TIMESTAMP. সবচেয়ে বড় প্রশ্ন time zone. ঢাকার সময় UTC-এর চেয়ে ৬ ঘণ্টা এগিয়ে। “2025-10-20 10:00” লেখা থাকলে সেটি ঢাকার সকাল দশটা, না লন্ডনের? PostgreSQL-এর TIMESTAMPTZ (timestamp with time zone) ঢোকার সময় মানটিকে UTC-তে রূপান্তর করে রাখে, আর দেখানোর সময় সংযোগের time zone-এ দেখায় — একাধিক দেশে চলা অ্যাপে এটিই নিরাপদ। MySQL-এর TIMESTAMP-ও UTC-তে রাখে, কিন্তু সীমা ২০৩৮ সালের ১৯ জানুয়ারি পর্যন্ত; DATETIME-এ time zone নেই। Oracle-এর DATE-এ সেকেন্ড পর্যন্ত সময়ও থাকে — নাম দেখে ভুল বুঝবেন না।

SQLite-এ তারিখের কোনো টাইপই নেই। প্রচলিত উপায় ISO 8601 লেখা: '2025-10-20' বা '2025-10-20 14:30:00'. এই ক্রমে (বছর-মাস-দিন) লিখলে লেখা হিসেবে সাজালেও তারিখের ক্রম ঠিক থাকে, আর SQLite-এর date(), strftime() ফাংশন এটি বোঝে (পর্ব ১৭)। '20/10/2025' লিখলে সাজানো আর তুলনা দুটিই ভুল হবে।

Boolean, BLOB, JSON, UUID আর ENUM

• Boolean: PostgreSQL-এ আসল BOOLEAN. MySQL-এ BOOLEAN আসলে TINYINT(1), SQL Server-এ BIT, SQLite-এ 0/1 পূর্ণসংখ্যা (TRUE লিখলে 1 জমা হয়)। Oracle-এ SQL-এর BOOLEAN এসেছে সাম্প্রতিক 23ai সংস্করণে; আগে NUMBER(1) বা CHAR(1).
• BLOB / binary: ছবি, PDF, এনক্রিপ্ট করা বাইট। PostgreSQL-এ BYTEA, SQL Server-এ VARBINARY(MAX). বড় ফাইল সাধারণত ডিস্ক বা cloud storage-এ রেখে ডেটাবেসে শুধু তার পথ রাখা হয়।
• JSON: PostgreSQL-এ JSON আর ভেতরে ভেঙে রাখা দ্রুততর JSONB; MySQL 5.7 থেকে JSON; SQLite-এ লেখা হিসেবে রেখে JSON ফাংশন দিয়ে পড়া। পর্ব ৩০-এ বিস্তারিত।
• UUID: PostgreSQL-এ নিজস্ব UUID টাইপ (১৬ বাইট), SQL Server-এ UNIQUEIDENTIFIER, MySQL-এ সাধারণত BINARY(16) বা CHAR(36).
• ENUM বনাম CHECK: “status চারটি শব্দের একটি” — MySQL-এ ENUM('pending','shipped',…), PostgreSQL-এ CREATE TYPE … AS ENUM. Portable উপায় CHECK: CHECK (status IN ('pending', 'shipped', 'delivered', 'cancelled')), যা db-shop-এর orders-এ আছে। তালিকা প্রায়ই বদলালে আলাদা lookup টেবিল আর foreign key (যেমন categories) সবচেয়ে নমনীয়।

টেবিলটি মুখস্থের জন্য নয়। শিক্ষাটি হলো: SQL standard থাকলেও টাইপের নাম আর আচরণ DBMS ভেদে আলাদা, তাই এক সিস্টেম থেকে আরেকটিতে schema সরানোর সময় প্রতিটি টাইপ মিলিয়ে নিতে হয় (পর্ব ৩১)। SQL Server আর অন্যদের নতুন সংস্করণে টাইপ যোগ হচ্ছে, তাই নিজের সংস্করণের ডকুমেন্টেশন দেখে নিন।

৪ · SQLite-এর type affinity আর STRICT টেবিল

এখন এমন একটি বিষয়, যা শুধু SQLite-এর — অন্য কোনো বড় DBMS-এ এমন হয় না। PostgreSQL-এ INTEGER কলামে 'abc' ঢোকাতে গেলে সঙ্গে সঙ্গে ত্রুটি। SQLite-এর সাধারণ টেবিলে তা ঢুকে যায়! কারণ SQLite dynamic typing ব্যবহার করে: টাইপ থাকে প্রতিটি মানের সাথে, কলামের সাথে নয়। কলামের ঘোষিত টাইপ শুধু একটি “পছন্দ” — একে বলে type affinity. মান ঢোকার সময় SQLite সেটিকে পছন্দের টাইপে বদলানোর চেষ্টা করে; ক্ষতি ছাড়া বদলানো গেলে বদলায়, না গেলে যেমন আছে তেমনই রাখে।

কোন কলামের affinity কী হবে, তা ঠিক হয় ঘোষিত টাইপের নামের ভেতরে কোন অক্ষরগুচ্ছ আছে তা দেখে — পাঁচটি নিয়ম, এই ক্রমেই। নিচে '007' লেখাটি বিভিন্ন কলামে ঢোকালে কী হয়, দেখুন:

এবার আসল SQLite-এ দেখুন। টেবিলটি একটি Excel ফাইল থেকে স্টক আমদানির মতো — যেখানে কেউ পরিমাণের ঘরে “বারো” লিখেছেন, দামের ঘরে “N/A”. typeof() ফাংশন প্রতিটি মানের আসল টাইপ বলে:

-- সাধারণ (non-STRICT) টেবিল: note কলামে টাইপই নেই
CREATE TABLE stock_loose (qty INTEGER, price REAL, code TEXT, note);
INSERT INTO stock_loose VALUES ('12', '450.00', 0172, '12');
INSERT INTO stock_loose VALUES ('বারো', 'N/A', 'A-7', 12);
INSERT INTO stock_loose VALUES (3.0, 99, 3.5, 3.0);
SELECT qty, typeof(qty), price, typeof(price),
       code, typeof(code), note, typeof(note)
FROM stock_loose;

নমনীয়তার এই দাম এড়াতে SQLite 3.37.0 (২০২১) থেকে STRICT টেবিল এসেছে: টেবিলের শেষে STRICT লিখলে কলামের টাইপ হতে হবে INT, INTEGER, REAL, TEXT, BLOB বা ANY-এর একটি, আর ক্ষতি ছাড়া বদলানো না গেলে মান ফিরিয়ে দেওয়া হয়। একই আমদানি এবার STRICT টেবিলে:

CREATE TABLE stock_strict (qty INTEGER, price REAL, code TEXT) STRICT;

-- ক্ষতি ছাড়া বদলানো যায়: '12' → 12, '450.00' → 450.0, 3.0 → 3
INSERT INTO stock_strict VALUES ('12', '450.00', '0172');
INSERT INTO stock_strict VALUES (3.0, 99, 'A-7');
SELECT qty, typeof(qty), price, typeof(price), code FROM stock_strict;

-- 'বারো' কোনোভাবেই পূর্ণসংখ্যা নয়: বাতিল
INSERT INTO stock_strict VALUES ('বারো', 450, 'A-8');

৫ · Constraint — কলামের পাশে নাকি টেবিলের শেষে

পর্ব ৬-এ দেখেছেন integrity constraint কী আর কেন। এখানে প্রশ্ন হলো, SQL-এ সেগুলো লেখা হয় কীভাবে। দুটি জায়গায় লেখা যায়:

• Column constraint — কলামের সংজ্ঞার পাশেই, শুধু সেই কলামের জন্য: name TEXT NOT NULL, phone TEXT UNIQUE, stock INTEGER CHECK (stock >= 0).
• Table constraint — সব কলামের পরে, আলাদা লাইনে; একাধিক কলাম জড়িত নিয়ম এখানেই লিখতে হয়: PRIMARY KEY (order_id, product_id), UNIQUE (product_id, customer_id), CHECK (sale_price <= price), FOREIGN KEY (…) REFERENCES ….

এক কলামের নিয়ম দুই জায়গাতেই লেখা যায় — phone TEXT UNIQUE আর শেষে UNIQUE (phone) একই। কিন্তু NOT NULL আর DEFAULT শুধু কলামের পাশে বসে। এক নজরে ছয়টি নিয়ম:

চাহিদার তালিকা থেকে কীভাবে একটি পূর্ণ টেবিল-সংজ্ঞা গড়ে ওঠে, ধাপে ধাপে দেখুন। প্রতিটি কলামের জন্য তিনটি প্রশ্ন: কোন টাইপ? খালি থাকতে পারে? আর কোন নিয়ম?

নিয়ম ভেঙে দেখুন — NOT NULL, UNIQUE আর PRIMARY KEY

এই এডিটর নিজের একটি ছোট টেবিল বানিয়ে নেয়: sellers (seller_id, shop_name, phone, trade_license), যেখানে shop_name NOT NULL, phone NOT NULL UNIQUE, trade_license UNIQUE, আর আগে থেকে একজন বিক্রেতা আছেন — (1, 'Rahim Store', '01711000001', 'TL-1001'). রানার প্রথম ত্রুটিতেই থামে, তাই মন্তব্য করা লাইনগুলো একবারে একটি করে চালু করে দেখুন:

-- বৈধ: সব নিয়ম মানছে (trade_license অজানা, NULL চলে)
INSERT INTO sellers VALUES (2, 'Karim Traders', '01811000002', NULL);

-- নিচের যেকোনো একটির সামনের -- মুছে চালান:
-- INSERT INTO sellers VALUES (2, 'Mitu Fashion', '01911000003', NULL);
-- INSERT INTO sellers VALUES (3, 'Mitu Fashion', '01711000001', NULL);
-- INSERT INTO sellers VALUES (3, 'Mitu Fashion', '01911000003', 'TL-1001');

-- দোকানের নাম নেই: NOT NULL ভাঙে
INSERT INTO sellers VALUES (3, NULL, '01911000003', 'TL-1003');

DEFAULT কাজের সময়

DEFAULT-এ ধ্রুব মান ('pending', 0) বা কিছু বিশেষ ফাংশন বসে, যেমন CURRENT_TIMESTAMP — সারি ঢোকার মুহূর্তের তারিখ-সময়। এই এডিটর একটি নতুন অর্ডার-টেবিল বানায়, যেখানে status, qty আর created_at-এর ডিফল্ট আছে:

CREATE TABLE orders_new (
  order_id    INTEGER PRIMARY KEY,
  customer_id INTEGER NOT NULL,
  status      TEXT NOT NULL DEFAULT 'pending',
  qty         INTEGER NOT NULL DEFAULT 1,
  created_at  TEXT NOT NULL DEFAULT CURRENT_TIMESTAMP
);
-- শুধু customer_id দিলাম, বাকি সব ডিফল্ট থেকে
INSERT INTO orders_new (customer_id) VALUES (3);
INSERT INTO orders_new (customer_id, status, qty) VALUES (5, 'shipped', 2);
SELECT * FROM orders_new;
-- ইচ্ছে করে NULL দিলে DEFAULT খাটে না
INSERT INTO orders_new (customer_id, status) VALUES (8, NULL);

৬ · CHECK, named constraint আর FOREIGN KEY

CHECK একটি সারির ভেতরের যেকোনো শর্ত লিখতে দেয়। কলামের পাশে লিখলে সাধারণত শুধু সেই কলামের শর্ত; টেবিলের শেষে লিখলে একাধিক কলাম তুলনা করা যায়, যেমন “ছাড়ের দাম আসল দামের বেশি নয়”। CONSTRAINT নাম দিয়ে নাম দিলে ত্রুটির বার্তায় সেই নাম আসে — বড় schema-য় “কোন নিয়ম ভাঙল” খোঁজার সময় এটি অনেক সময় বাঁচায়:

CREATE TABLE price_list (
  item       TEXT NOT NULL PRIMARY KEY,
  price      INTEGER NOT NULL CONSTRAINT chk_price CHECK (price > 0),
  sale_price INTEGER,
  CONSTRAINT chk_sale CHECK (sale_price <= price)    -- table-level
);
INSERT INTO price_list VALUES ('Panjabi', 2200, 1990);
INSERT INTO price_list VALUES ('Saree', 4500, NULL);    -- ছাড় নেই
-- INSERT INTO price_list VALUES ('Lungi', 0, NULL);
INSERT INTO price_list VALUES ('Shawl', 1500, 1800);   -- ছাড়ে দাম বেশি!

FOREIGN KEY — কলামে বা টেবিলের শেষে

পর্ব ৬-এ foreign key-র অর্থ আর ON DELETE / ON UPDATE-এর referential action (CASCADE, SET NULL, RESTRICT) দেখেছেন। লেখার দুটি রূপ: কলামের পাশে customer_id INTEGER REFERENCES customers (customer_id), অথবা টেবিলের শেষে FOREIGN KEY (customer_id) REFERENCES customers (customer_id) ON DELETE … — composite foreign key-র জন্য দ্বিতীয়টিই একমাত্র উপায়। db-shop-এ একটি নতুন reviews টেবিল বানাই, যেখানে সব ধরনের table constraint একসাথে:

CREATE TABLE reviews (
  review_id   INTEGER PRIMARY KEY,
  product_id  INTEGER NOT NULL,
  customer_id INTEGER NOT NULL,
  stars       INTEGER NOT NULL CHECK (stars BETWEEN 1 AND 5),
  UNIQUE (product_id, customer_id),          -- এক পণ্যে একজনের একটি রিভিউ
  FOREIGN KEY (product_id) REFERENCES products (product_id) ON DELETE CASCADE,
  FOREIGN KEY (customer_id) REFERENCES customers (customer_id)
);
-- Karima Begum (2) DSA Book (104)-কে ৫ তারা দিলেন
INSERT INTO reviews VALUES (1, 104, 2, 5);
-- গ্রাহক 99 নেই
INSERT INTO reviews VALUES (2, 104, 99, 4);

একটি INSERT-এ DBMS কী কী যাচাই করে

সব নিয়ম একসাথে দেখি। নিচে db-shop-এর products টেবিলে (price REAL, stock DEFAULT 0) একটি নতুন পণ্য ঢুকছে: INSERT INTO products (product_id, name, price) VALUES (111, 'Lungi', '350'); — খেয়াল করুন, দাম দেওয়া হয়েছে লেখা হিসেবে।

৭ · Auto-increment id — প্রতিটি DBMS-এর নিজের নাম

Surrogate primary key-র মান সাধারণত DBMS নিজেই দেয় — ব্যাংকের টোকেন মেশিনের মতো, প্রত্যেকে পরের নম্বর পান। কিন্তু লেখার নিয়ম প্রতিটি সিস্টেমে আলাদা, আর এখানে SQL-এর উপভাষাগুলোর পার্থক্য সবচেয়ে চোখে পড়ে।

SQLite: প্রতিটি সাধারণ টেবিলে একটি লুকানো ৬৪-বিটের rowid থাকে। INTEGER PRIMARY KEY লিখলে কলামটি ঠিক এই rowid-এর আরেক নাম হয়ে যায়; মান না দিলে (বা NULL দিলে) SQLite সাধারণত বর্তমান সর্বোচ্চ rowid + 1 বসায়। বানান হুবহু INTEGER হতে হবে — INT PRIMARY KEY লিখলে এটি rowid-এর নাম হয় না, সাধারণ কলাম থাকে। আর AUTOINCREMENT যোগ করলে একটি বাড়তি নিশ্চয়তা আসে: মুছে ফেলা সারির নম্বর আর কখনো ফিরে আসে না। পার্থক্যটি দেখুন:

CREATE TABLE a (id INTEGER PRIMARY KEY, name TEXT);
CREATE TABLE b (id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT);
INSERT INTO a (name) VALUES ('Rahim'), ('Karima'), ('Sabbir');
INSERT INTO b (name) VALUES ('Rahim'), ('Karima'), ('Sabbir');
-- সবচেয়ে বড় id (3) মুছে নতুন একজন
DELETE FROM a WHERE id = 3;
DELETE FROM b WHERE id = 3;
INSERT INTO a (name) VALUES ('Nusrat');
INSERT INTO b (name) VALUES ('Nusrat');
SELECT 'a' AS tbl, id, name FROM a
UNION ALL SELECT 'b', id, name FROM b;
SELECT * FROM sqlite_sequence;

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

CREATE TABLE customers (
  customer_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  name        TEXT NOT NULL,
  joined_on   TIMESTAMPTZ NOT NULL DEFAULT now()
);
-- পুরোনো (PostgreSQL 10-এর আগের) লেখা:
-- customer_id SERIAL PRIMARY KEY

CREATE TABLE customers (
  customer_id BIGINT AUTO_INCREMENT PRIMARY KEY,
  name        VARCHAR(100) NOT NULL,
  joined_on   DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4;

CREATE TABLE customers (
  customer_id BIGINT IDENTITY(1,1) PRIMARY KEY,   -- শুরু 1, প্রতিবার +1
  name        NVARCHAR(100) NOT NULL,
  joined_on   DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME()
);

CREATE TABLE customers (
  customer_id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,  -- 12c থেকে
  name        VARCHAR2(100 CHAR) NOT NULL,
  joined_on   TIMESTAMP WITH TIME ZONE DEFAULT SYSTIMESTAMP NOT NULL
);

PostgreSQL-এ SERIAL আসলে কোনো টাইপ নয়, একটি সংক্ষিপ্ত রূপ: এটি একটি sequence (নম্বর বিতরণের আলাদা বস্তু) বানায় আর কলামের DEFAULT-এ nextval(…) বসায়। এতে কেউ হাতে id দিয়ে ফেললে sequence জানতে পারে না, আর পরে একই নম্বর এসে primary key-তে ধাক্কা খায়। SQL standard-এর identity column (PostgreSQL 10, ২০১৭ থেকে) এটি পরিষ্কার করে: GENERATED ALWAYS হাতে দেওয়া মান ফিরিয়ে দেয় (জরুরি দরকারে OVERRIDING SYSTEM VALUE লিখতে হয়), আর GENERATED BY DEFAULT হাতে দেওয়া মান মেনে নেয়। নতুন প্রজেক্টে identity ব্যবহার করুন।

৮ · CREATE TABLE AS SELECT আর schema-র নামঘর

কখনো নতুন টেবিল শূন্য থেকে নয়, একটি কোয়েরির ফল থেকে বানাতে হয় — রিপোর্টের জন্য ঢাকার গ্রাহকদের আলাদা কপি, বা বড় পরিবর্তনের আগে একটি ব্যাকআপ। এর জন্য CREATE TABLE … AS SELECT (সংক্ষেপে CTAS): SELECT-এর ফলের কলাম দিয়ে কাঠামো, আর সারিগুলো দিয়ে ডেটা। কিন্তু কী কী কপি হয় না, সেটি জানা জরুরি:

-- ঢাকার গ্রাহকদের আলাদা কপি: কাঠামো + ডেটা
CREATE TABLE dhaka_customers AS
  SELECT customer_id, name, phone, joined_on
  FROM customers WHERE city = 'Dhaka';
SELECT * FROM dhaka_customers;
PRAGMA table_info(dhaka_customers);

-- শুধু কাঠামো, ডেটা নয়: কখনো সত্য হয় না এমন শর্ত
CREATE TABLE products_empty AS SELECT * FROM products WHERE 1 = 0;
SELECT COUNT(*) AS n FROM products_empty;

অন্য সিস্টেমে: PostgreSQL আর Oracle-এ একই CREATE TABLE … AS SELECT; SQL Server-এ লেখা হয় SELECT … INTO new_table FROM …. শুধু কাঠামো নিখুঁতভাবে (constraint আর index-সহ) কপি করতে PostgreSQL-এ CREATE TABLE new (LIKE old INCLUDING ALL), MySQL-এ CREATE TABLE new LIKE old.

Schema — টেবিলের নামঘর

একটি বড় প্রতিষ্ঠানের ডেটাবেসে শত শত টেবিল। হিসাব বিভাগের reports আর বিক্রয় বিভাগের reports আলাদা হলে? সমাধান namespace, যাকে SQL-এ schema বলে — একটি নামযুক্ত ফোল্ডার, যার ভেতরে টেবিল থাকে। পুরো নাম লেখা হয় schema.table:

CREATE SCHEMA sales;
CREATE TABLE sales.reports   (report_id BIGINT PRIMARY KEY, title TEXT);
CREATE TABLE finance.reports (report_id BIGINT PRIMARY KEY, amount NUMERIC(14,2));
-- schema না লিখলে কোথায় খুঁজবে, ঠিক করে search_path (ডিফল্ট public)
SET search_path TO sales, public;

PostgreSQL-এর স্তর তিনটি: ডেটাবেস → schema → টেবিল, আর নতুন টেবিল ডিফল্টভাবে public schema-য় যায়। MySQL-এ SCHEMA আর DATABASE একই জিনিস, তাই shop.customers মানে “shop ডেটাবেসের customers”. SQL Server-এ ডিফল্ট schema dbo, Oracle-এ প্রতিটি ব্যবহারকারীর নামেই একটি schema. SQLite-এ মূল ফাইলটি main, অস্থায়ী টেবিল থাকে temp-এ, আর ATTACH DATABASE 'archive.db' AS archive করে আরেকটি ফাইলকে archive.orders নামে ব্যবহার করা যায়। Schema শুধু নাম সাজায় না, অনুমতিও ভাগ করে: “বিক্রয় দল শুধু sales schema পড়তে পারবে” (পর্ব ৫১)।

৯ · AI-এর যুগে CREATE TABLE

AI-কে “একটা দোকানের টেবিল বানিয়ে দাও” বললে চমৎকার দেখতে CREATE TABLE আসে, আর সেটি চলেও। কিন্তু টাইপ আর constraint-এর ভুল প্রথম দিনে ধরা পড়ে না — পড়ে ছয় মাস পরে, যখন হিসাব মেলে না বা ফোন নম্বরের শূন্য হারিয়ে গেছে। AI প্রায়ই যা করে:

AI-এর দেওয়া CREATE TABLE হাতে পেলে — যাচাইয়ের চেকলিস্ট

• টাইপগুলো আমার DBMS-এর (SQLite-এ SERIAL নেই, MySQL-এ TIMESTAMPTZ নেই)
• টাকা DECIMAL বা পূর্ণসংখ্যা পয়সায়; ফোন, NID, পোস্ট কোড লেখা হিসেবে
• প্রতিটি কলামের NULL-নীতি ভেবে দেখেছি; বাধ্যতামূলক তথ্যে NOT NULL
• প্রতিটি constraint ভাঙার INSERT চালিয়েছি — ত্রুটি না এলে নিয়মটি কাজ করছে না
• PRAGMA table_info (বা \d, DESCRIBE) দিয়ে তৈরি হওয়া কাঠামো চোখে দেখেছি
• নমুনা ডেটা ঢুকিয়ে SUM, COUNT হাতে করা হিসাবের সাথে মিলিয়েছি