ক্যাপস্টোন — ডিজাইন থেকে deployment পর্যন্ত একটি সম্পূর্ণ ডেটাবেস

১ · প্রয়োজন আর ব্যবসার নিয়ম — ক্লিনিকের কথা শুনে লেখা

মিরপুরের একটি কাল্পনিক “ঢাকা কমিউনিটি হেলথ ক্লিনিক”. প্রতি সন্ধ্যায় ছয়জন ডাক্তার চেম্বারে বসেন — মেডিসিন, শিশু, গাইনি আর চর্মরোগ। এখন বুকিং হয় একটি বাঁধানো খাতায় আর ফোনে। সমস্যা প্রতিদিনের: একই সময়ে দুজন রোগীর নাম, কে টাকা দিলেন তার হিসাব মেলে না, আর পুরোনো prescription খুঁজতে খাতার পাতা ওল্টাতে হয়। ক্লিনিক চায় এমন একটি সিস্টেম, যেখানে দুজন receptionist আর একটি ওয়েবসাইট একসাথে বুকিং নিতে পারে।

পেশাদার কাজ শুরু হয় কোড দিয়ে নয়, কথা শুনে (requirements analysis, পর্ব ৭)। ক্লিনিকের ম্যানেজার, দুজন receptionist আর একজন ডাক্তারের সাথে কথা বলে নিচের ব্যবসার নিয়ম লেখা হলো। প্রতিটির একটি নম্বর — পরের প্রতিটি অংশে দেখবেন কোন নিয়ম কোথায় রক্ষা হলো:

সাথে কয়েকটি অ-কার্যকরী (non-functional) প্রয়োজন, যেগুলো পরে ডিজাইন ঠিক করে দেবে: একসাথে তিনটি জায়গা থেকে বুকিং; বিপর্যয়ে সর্বোচ্চ ৫ মিনিটের ডেটা হারানো চলবে আর ১ ঘণ্টার মধ্যে সেবা ফিরতে হবে; আর রোগীর তথ্য স্বাস্থ্য-সংক্রান্ত, তাই গোপনীয়তা সবচেয়ে কঠোর। নিচের stepper-এ দেখুন একটি বাক্য থেকে কীভাবে entity আর নিয়ম বেরিয়ে আসে:

২ · ধারণাগত ER আর মূল সিদ্ধান্ত

পর্ব ৭–৮-এর চিহ্নে পুরো সিস্টেমের ER ডায়াগ্রাম। আয়তক্ষেত্র entity, দুই-রেখার আয়তক্ষেত্র weak entity, রেখার পাশে সংখ্যা cardinality:

ডায়াগ্রামের পেছনের পাঁচটি সিদ্ধান্ত, আর প্রতিটির বিকল্প কেন বাদ:

৫. Key আর সময়। প্রতিটি টেবিলে ছোট সংখ্যার surrogate key, আর বাস্তবের অনন্য পরিচয়গুলো — ডাক্তারের BMDC নিবন্ধন নম্বর, রোগীর ফোন, bKash-এর trx ID — আলাদা UNIQUE (পর্ব ৬)। ফোন নম্বর key বানাইনি, কারণ মানুষ নম্বর বদলান, আর পরিবারের কয়েকজন একটি নম্বর ভাগ করতে পারেন — সেটি এলে UNIQUE তুলে দেওয়া সহজ, primary key বদলানো নয়। সময় রাখা হয়েছে ঢাকার স্থানীয় সময়ে ISO-8601 টেক্সটে ('2026-11-05 17:30:00'), যাতে টেক্সটের ক্রম আর সময়ের ক্রম এক থাকে; PostgreSQL-এ একই কাজ timestamptz করে (পর্ব ১৩, ১৭)।

৩ · Logical schema — CREATE TABLE, constraint আর normalization

পর্ব ১০-এর mapping নিয়ম প্রয়োগ করলে আটটি টেবিল আসে: প্রতিটি strong entity একটি টেবিল; প্রতিটি 1:N relationship “N” দিকে একটি foreign key; weak entity-র primary key = owner-এর key + partial key. নিচে পুরো schema — এই পর্বের প্রতিটি লাইভ এডিটর এটি দিয়েই শুরু হয় (এডিটরের “নমুনা ডেটাবেস” বাক্সে নমুনা ডেটাসহ দেখতে পাবেন):

-- ঢাকা কমিউনিটি হেলথ ক্লিনিক: schema (পর্ব ৬২)
CREATE TABLE specialities (
  spec_id INTEGER PRIMARY KEY,
  name    TEXT NOT NULL UNIQUE
);
CREATE TABLE doctors (
  doctor_id INTEGER PRIMARY KEY,
  name      TEXT NOT NULL,
  spec_id   INTEGER NOT NULL REFERENCES specialities(spec_id) ON DELETE RESTRICT,
  reg_no    TEXT NOT NULL UNIQUE,              -- BMDC নিবন্ধন নম্বর
  fee       INTEGER NOT NULL CHECK (fee BETWEEN 100 AND 5000)   -- টাকা
);
CREATE TABLE patients (
  patient_id INTEGER PRIMARY KEY,
  name       TEXT NOT NULL,
  phone      TEXT NOT NULL UNIQUE CHECK (length(phone) = 11 AND phone LIKE '01%'),
  birth_year INTEGER CHECK (birth_year BETWEEN 1900 AND 2026)
);
CREATE TABLE slots (
  slot_id    INTEGER PRIMARY KEY,
  doctor_id  INTEGER NOT NULL REFERENCES doctors(doctor_id) ON DELETE RESTRICT,
  slot_start TEXT NOT NULL,                    -- 'YYYY-MM-DD HH:MM:SS', ঢাকার সময়
  slot_end   TEXT NOT NULL,
  CHECK (slot_end > slot_start),
  UNIQUE (doctor_id, slot_start)               -- একই ডাক্তারের একই সময়ে দুটি slot নয়
);
CREATE TABLE appointments (
  appt_id      INTEGER PRIMARY KEY,
  slot_id      INTEGER NOT NULL REFERENCES slots(slot_id) ON DELETE RESTRICT,
  patient_id   INTEGER NOT NULL REFERENCES patients(patient_id) ON DELETE RESTRICT,
  status       TEXT NOT NULL DEFAULT 'booked'
               CHECK (status IN ('booked', 'completed', 'no_show', 'cancelled')),
  booked_at    TEXT NOT NULL,
  cancelled_at TEXT,
  CHECK ((status = 'cancelled') = (cancelled_at IS NOT NULL))
);
-- নিয়ম ১: একটি slot-এ বাতিল-নয় এমন appointment সর্বোচ্চ একটি
CREATE UNIQUE INDEX appt_one_active_per_slot
  ON appointments(slot_id) WHERE status <> 'cancelled';
-- নিয়ম ২: একজন রোগীর একই সময়ে দুটি সক্রিয় appointment নয়
CREATE TRIGGER appt_no_patient_overlap
BEFORE INSERT ON appointments WHEN NEW.status <> 'cancelled'
BEGIN
  SELECT RAISE(ABORT, 'patient already has an appointment at this time')
  WHERE EXISTS (
    SELECT 1 FROM appointments a
    JOIN slots s  ON s.slot_id = a.slot_id
    JOIN slots ns ON ns.slot_id = NEW.slot_id
    WHERE a.patient_id = NEW.patient_id AND a.status <> 'cancelled'
      AND s.slot_start < ns.slot_end AND ns.slot_start < s.slot_end);
END;
CREATE TABLE prescriptions (
  rx_id      INTEGER PRIMARY KEY,
  appt_id    INTEGER NOT NULL UNIQUE REFERENCES appointments(appt_id) ON DELETE RESTRICT,
  diagnosis  TEXT NOT NULL,
  written_at TEXT NOT NULL
);
CREATE TABLE prescription_items (
  rx_id    INTEGER NOT NULL REFERENCES prescriptions(rx_id) ON DELETE CASCADE,
  line_no  INTEGER NOT NULL CHECK (line_no >= 1),
  medicine TEXT NOT NULL,
  dosage   TEXT NOT NULL,                      -- যেমন '1+0+1'
  days     INTEGER NOT NULL CHECK (days BETWEEN 1 AND 365),
  PRIMARY KEY (rx_id, line_no)
);
CREATE TABLE payments (
  pay_id  INTEGER PRIMARY KEY,
  appt_id INTEGER NOT NULL REFERENCES appointments(appt_id) ON DELETE RESTRICT,
  method  TEXT NOT NULL CHECK (method IN ('bkash', 'cash')),
  amount  INTEGER NOT NULL CHECK (amount > 0),
  trx_id  TEXT UNIQUE,                         -- bKash লেনদেনের ID
  paid_at TEXT NOT NULL,
  CHECK ((method = 'bkash') = (trx_id IS NOT NULL))
);

এখানে প্রতিটি constraint একটি নিয়মের পাহারাদার। কয়েকটি সিদ্ধান্ত বিশেষভাবে লক্ষ করুন:

• দুই কলামের CHECK: (status = 'cancelled') = (cancelled_at IS NOT NULL) — বাতিল হলে সময় থাকতেই হবে, আর বাতিল না হলে সময় থাকা চলবে না (R3). একই কৌশলে bKash ⇔ trx ID (R5). দুই দিকের “যদি এবং কেবল যদি” একটি সমতায়।
• Referential action: প্রায় সব foreign key ON DELETE RESTRICT. চিকিৎসার ইতিহাস কখনো নিঃশব্দে মুছে যাওয়া চলবে না — যে ডাক্তারের appointment আছে, তাঁকে মোছা যাবে না; চাকরি ছাড়লে একটি “inactive” চিহ্ন যথেষ্ট। একমাত্র ব্যতিক্রম prescription_items-এ ON DELETE CASCADE: ওষুধের লাইনের অস্তিত্ব prescription-এর ওপর নির্ভরশীল (পর্ব ২৩)।
• টাকা INTEGER-এ: ফি পূর্ণ টাকায়, তাই INTEGER; পয়সা লাগলে পয়সায় পূর্ণসংখ্যা বা PostgreSQL-এ numeric(10,2) — কখনো floating point নয়।

এবার constraint-গুলো কাজে দেখুন। নতুন একজন রোগী খালি slot ৩৯-এ (Dr. Farhana Rahman, ৫ নভেম্বর সন্ধ্যা ৬:৩০) appointment নিলেন; তারপর receptionist bKash-এ টাকা নিয়ে লেনদেনের ID লিখতে ভুলে গেলেন:

-- নতুন রোগী আর একটি খালি slot-এ (39) তাঁর appointment
INSERT INTO patients VALUES (121, 'Ayesha Siddiqua', '01812345678', 1994);
INSERT INTO appointments (slot_id, patient_id, booked_at)
VALUES (39, 121, '2026-11-04 10:00:00');
SELECT a.appt_id, s.slot_start, d.name AS doctor, d.fee, a.status
FROM appointments a JOIN slots s ON s.slot_id = a.slot_id
JOIN doctors d ON d.doctor_id = s.doctor_id WHERE a.patient_id = 121;
-- bKash-এ টাকা নেওয়া হলো, কিন্তু লেনদেনের ID লেখা হয়নি
INSERT INTO payments (appt_id, method, amount, paid_at)
VALUES (178, 'bkash', 800, '2026-11-05 18:50:00');

Normalization যাচাই — FD থেকে BCNF

পুরোনো খাতার একটি পাতা আসলে একটি চওড়া টেবিল: register(appt_no, slot_start, doctor, reg_no, speciality, fee, patient_phone, patient_name, diagnosis, medicines, method, trx_id, amount). পর্ব ৩৫-এর মতো functional dependency লিখি:

• reg_no → doctor, speciality, fee  ·  patient_phone → patient_name
• appt_no → slot_start, reg_no, patient_phone, diagnosis  ·  trx_id → appt_no, amount
• (reg_no, slot_start) → appt_no — কিন্তু শুধু সক্রিয় appointment-এর জন্য

এই টেবিলের key appt_no (সাথে ওষুধের লাইন), অথচ reg_no → fee একটি transitive dependency: appt_no → reg_no → fee. তাই এটি 3NF নয় (পর্ব ৩৬) — ফি বদলালে শত সারি বদলাতে হয়, নতুন ডাক্তারের appointment না হওয়া পর্যন্ত তাঁকে লেখাই যায় না। প্রতিটি FD-র determinant-কে নিজের টেবিলের key বানিয়ে ভাঙলে ঠিক আমাদের আটটি টেবিল আসে। এবার প্রমাণ যে প্রতিটি টেবিল BCNF: সংজ্ঞা অনুযায়ী প্রতিটি অ-তুচ্ছ FD X → Y-এ X একটি superkey হতে হবে (পর্ব ৩৭)।

• doctors: FD দুটি — doctor_id → সব, reg_no → সব। দুটি determinant-ই candidate key. BCNF.
• slots: slot_id → সব, আর (doctor_id, slot_start) → সব (UNIQUE-এর কারণে)। দুটিই candidate key. BCNF.
• appointments: appt_id → সব। slot_id → patient_id কি FD? না — slot ১৯৫-এ বাতিল আর নতুন, দুই রোগীর দুটি সারি আছে। তাই অন্য কোনো অ-তুচ্ছ FD নেই। BCNF.
• payments: pay_id → সব, trx_id → সব (NULL বাদে অনন্য)। BCNF. বাকি টেবিলগুলোতেও প্রতিটি determinant একটি candidate key — যেমন patients-এ patient_id আর phone, prescriptions-এ rx_id আর appt_id, prescription_items-এ (rx_id, line_no); তাই সবগুলোই BCNF.

দুটি সূক্ষ্মতা। এক, “সক্রিয় হলে slot_id → appt_id” একটি শর্তসাপেক্ষ নির্ভরতা — প্রথাগত FD তত্ত্ব এটি প্রকাশ করতে পারে না, তাই এটি normalization নয়, constraint (partial index) দিয়ে রক্ষা হয়। দুই, payments.amount আর doctors.fee কি একই তথ্যের দুই কপি? না। ফি আজকের দাম; amount সেদিন আসলে যা নেওয়া হয়েছিল — ঐতিহাসিক ঘটনা। আগামী মাসে ফি বাড়লে পুরোনো আয়ের রিপোর্ট বদলানো উচিত নয়। এটি redundancy নয়, ভিন্ন অর্থের দুটি তথ্য (পর্ব ৩৮)।

৪ · নমুনা ডেটা — recursive CTE দিয়ে বাস্তবের মতো ডেটা

খালি টেবিলে কোয়েরি লেখা মানে অন্ধকারে লেখা। কোয়েরির ফল যাচাই, plan দেখা আর demo — সবকিছুর জন্য বাস্তবের মতো নমুনা ডেটা লাগে (seeding, পর্ব ৫০)। দুটি শর্ত: ডেটা নির্ধারিত (প্রতিবার হুবহু একই, যাতে ফল তুলনা করা যায়) আর constraint মানা। এজন্য random() নয়, সূত্র — আর সারি বানাতে পর্ব ২৫-এর recursive CTE. এই এডিটরে শুধু schema, বিভাগ, ছয়জন ডাক্তার আর ১২০ জন রোগী আছে; slot বানাবেন আপনি:

WITH RECURSIVE n(i) AS (SELECT 0 UNION ALL SELECT i + 1 FROM n WHERE i < 239)
INSERT INTO slots (doctor_id, slot_start, slot_end)
SELECT i / 40 + 1,
  datetime('2026-11-01 17:00', '+' || (i % 40 / 8) || ' days', '+' || (i % 8 * 15) || ' minutes'),
  datetime('2026-11-01 17:15', '+' || (i % 40 / 8) || ' days', '+' || (i % 8 * 15) || ' minutes')
FROM n;
-- যাচাই: প্রতি ডাক্তারের কয়টি slot, কোন দিনগুলোতে
SELECT doctor_id, COUNT(*) AS slots, MIN(slot_start) AS first_start,
       MAX(slot_end) AS last_end, COUNT(DISTINCT date(slot_start)) AS days
FROM slots GROUP BY doctor_id;
SELECT DISTINCT strftime('%w', slot_start) AS weekday FROM slots;

বাকি নমুনা ডেটা (“নমুনা ডেটাবেস” বাক্সের clinic-seed অংশ) একই নীতিতে বানানো: যে slot-এর নম্বর ১০ দিয়ে ভাগ করলে ভাগশেষ ৩, ৭ বা ৯, সেগুলো খালি — বাকি ৭০% বুক; ১৩-এর গুণিতক বাতিল; ৫ নভেম্বরেরগুলো এখনো সামনে। ফল: ২৪০টি slot, ১৭৭টি appointment (১১৭ completed, ১৮ no_show, ২৯ booked, ১৩ cancelled), ১১৭টি prescription আর ১১৭টি পেমেন্ট, মোট ১,০৯,০০০ টাকা।

রোগী বাছাইয়ের সূত্রটি R2 মানার একটি ছোট প্রমাণ বহন করে। একটি সময়-বিন্দু t (দিন × ৮ + slot-এর ক্রম, ০ থেকে ৩৯) আর ডাক্তার d (১–৬)-এর রোগী = ১ + (৬t + d − ১) mod ১২০. একই t-তে ছয়জন ডাক্তারের জন্য ৬t, ৬t + ১, …, ৬t + ৫ — পরপর ছয়টি সংখ্যা, আর ১২০-এর চেয়ে কম ব্যবধানের সংখ্যার ভাগশেষ আলাদা। তাই একই সময়ে কোনো রোগী দুই ডাক্তারের কাছে নেই, আর trigger-টি seed-এর একটি সারিও আটকায় না। ডেটা বানানোর সময় নিয়ম মানা নিশ্চিত করুন — কিন্তু তবুও constraint রাখুন, যাতে সূত্রে ভুল হলে ডেটাবেস জানিয়ে দেয়।

৫ · অ্যাপের আসল কোয়েরি — খালি slot, ইতিহাস, আয় আর ব্যস্ততা

ক. একটি দিনে একজন ডাক্তারের খালি slot

রোগী ওয়েবসাইটে ডাক্তার আর তারিখ বাছলে প্রথম কোয়েরি: কোন slot খালি? খালি মানে সেই slot-এর এমন কোনো appointment নেই যা বাতিল নয় — একটি anti-join (পর্ব ২০, ২১)। তারিখের শর্ত half-open পরিসরে, যাতে index কাজে লাগে (পর্ব ১৭):

-- Dr. Sharmin Akter (doctor_id 5), ৫ নভেম্বর: খালি slot কোনগুলো?
SELECT s.slot_id, time(s.slot_start) AS starts
FROM slots s
WHERE s.doctor_id = 5
  AND s.slot_start >= '2026-11-05' AND s.slot_start < '2026-11-06'
  AND NOT EXISTS (SELECT 1 FROM appointments a
                  WHERE a.slot_id = s.slot_id AND a.status <> 'cancelled')
ORDER BY s.slot_start;
-- প্রচলিত ভুল: status না দেখে LEFT JOIN … IS NULL
SELECT s.slot_id, time(s.slot_start) AS starts
FROM slots s LEFT JOIN appointments a ON a.slot_id = s.slot_id
WHERE s.doctor_id = 5 AND s.slot_start >= '2026-11-05'
  AND s.slot_start < '2026-11-06' AND a.appt_id IS NULL;

খ. একজন রোগীর পুরো ইতিহাস

ডাক্তার রোগী ৭-এর ফাইল খুললেন। দরকার প্রতিটি appointment, রোগনির্ণয়, ওষুধ আর পরিশোধ — যেগুলোর prescription বা পেমেন্ট নেই, সেগুলোও। এখানে একটি ফাঁদ: prescription_items আর payments দুটিই “অনেক” দিক; দুটিকে একসাথে JOIN করলে সারি গুণ হয় — fan-out (পর্ব ১৯): দুটি ওষুধ × একটি পেমেন্ট = দুটি সারি, আর SUM দ্বিগুণ। তাই “অনেক” দিকগুলো আলাদা scalar subquery-তে:

-- রোগী ৭-এর পুরো ইতিহাস
SELECT date(s.slot_start) AS day, time(s.slot_start) AS at, d.name AS doctor,
       a.status, rx.diagnosis,
       (SELECT group_concat(i.medicine, ', ' ORDER BY i.line_no)
          FROM prescription_items i WHERE i.rx_id = rx.rx_id) AS medicines,
       (SELECT SUM(p.amount) FROM payments p WHERE p.appt_id = a.appt_id) AS paid
FROM appointments a
JOIN slots s ON s.slot_id = a.slot_id
JOIN doctors d ON d.doctor_id = s.doctor_id
LEFT JOIN prescriptions rx ON rx.appt_id = a.appt_id
WHERE a.patient_id = 7
ORDER BY s.slot_start;

গ. দৈনিক আয় আর no-show-এর হার

ম্যানেজারের রিপোর্ট (R8): প্রতিদিন নগদ আর bKash আলাদা কলামে — conditional aggregation (পর্ব ১৮) — আর ডাক্তারপ্রতি no-show-এর হার। হারের হর নিয়ে সাবধান: বাতিল appointment বা যেগুলো এখনো সামনে, সেগুলো “এলেন কি না” প্রশ্নের অংশ নয়:

-- দৈনিক আয়: নগদ আর bKash আলাদা কলামে
SELECT date(paid_at) AS day,
       SUM(CASE WHEN method = 'cash'  THEN amount ELSE 0 END) AS cash,
       SUM(CASE WHEN method = 'bkash' THEN amount ELSE 0 END) AS bkash,
       SUM(amount) AS total
FROM payments GROUP BY date(paid_at) ORDER BY day;
-- no-show-এর হার: শুধু যেগুলোর ফল জানা (completed বা no_show)
SELECT d.name, SUM(a.status = 'no_show') AS no_shows, COUNT(*) AS decided,
       ROUND(100.0 * SUM(a.status = 'no_show') / COUNT(*), 1) AS no_show_pct
FROM appointments a JOIN slots s ON s.slot_id = a.slot_id
JOIN doctors d ON d.doctor_id = s.doctor_id
WHERE a.status IN ('completed', 'no_show')
GROUP BY d.doctor_id ORDER BY no_show_pct DESC, d.name;

ঘ. ডাক্তারের সময় কতটা কাজে লাগল — window function

“ব্যস্ততা” (utilisation) = যত slot-এ রোগী আসলে দেখা হলো ÷ মোট slot. সাথে দুটি তুলনা — সবার মধ্যে স্থান (RANK) আর নিজের বিভাগের গড় — যা GROUP BY একা দিতে পারে না, কারণ প্রতিটি সারির পাশে অন্য সারির হিসাব লাগে (পর্ব ২৬):

-- ১–৪ নভেম্বর: কোন ডাক্তারের সময় কতটা কাজে লেগেছে
WITH per_doc AS (
  SELECT s.doctor_id, COUNT(*) AS slots,
         SUM(a.status = 'completed') AS seen
  FROM slots s LEFT JOIN appointments a
    ON a.slot_id = s.slot_id AND a.status <> 'cancelled'
  WHERE s.slot_start < '2026-11-05'
  GROUP BY s.doctor_id)
SELECT d.name, p.seen, p.slots,
       ROUND(100.0 * p.seen / p.slots, 1) AS util_pct,
       RANK() OVER (ORDER BY 1.0 * p.seen / p.slots DESC) AS rnk,
       ROUND(AVG(100.0 * p.seen / p.slots) OVER (PARTITION BY d.spec_id), 1) AS spec_avg
FROM per_doc p JOIN doctors d ON d.doctor_id = p.doctor_id
ORDER BY rnk, d.name;

৬ · কঠিনতম নিয়ম — double booking ডেটাবেসেই আটকানো

অ্যাপের সবচেয়ে স্বাভাবিক কোড: “আগে দেখো slot খালি কি না; খালি হলে INSERT”. একজন ব্যবহারকারী থাকলে এটি কাজ করে। দুজন একই মুহূর্তে হলে দুজনই “খালি” দেখেন, দুজনই INSERT করেন — check-then-act ধরনের race condition. দেখা আর লেখার মাঝের ফাঁকটি কোনো অ্যাপ-কোড বন্ধ করতে পারে না। বন্ধ করে ডেটাবেসের constraint, কারণ constraint-এর যাচাই আর লেখা ডেটাবেসের ভেতরে একসাথে, একটি অবিভাজ্য কাজে ঘটে।

R1-এর জন্য শুধু UNIQUE (slot_id) দেওয়া যেত না — তাহলে বাতিল slot আর কখনো বুক করা যেত না। দরকার শর্তসাপেক্ষ অনন্যতা: CREATE UNIQUE INDEX … ON appointments(slot_id) WHERE status <> 'cancelled' — একটি partial index, যা শুধু সক্রিয় সারির হিসাব রাখে:

-- slot 195 (Dr. Sharmin Akter, ৫ নভেম্বর ৫:৩০): আগের appointment বাতিল
SELECT appt_id, patient_id, status, cancelled_at FROM appointments WHERE slot_id = 195;
-- বাতিল slot আবার বুক করা যায় — partial index শুধু সক্রিয় সারি দেখে
INSERT INTO appointments (slot_id, patient_id, booked_at)
VALUES (195, 30, '2026-11-04 09:00:00');
SELECT appt_id, patient_id, status FROM appointments WHERE slot_id = 195;
-- দ্বিতীয় receptionist একই slot-এ আরেকজনকে বসাতে চাইলেন
INSERT INTO appointments (slot_id, patient_id, booked_at)
VALUES (195, 31, '2026-11-04 09:00:05');

R2 — একই রোগীর একই সময়ে দুটি appointment নয় — আরও কঠিন, কারণ সময় থাকে slots-এ আর রোগী appointments-এ: নিয়মটি দুই টেবিল জুড়ে। SQLite-এ এর জন্য একটি BEFORE INSERT trigger (পর্ব ২৯), যা দুটি সময়ের ছেদ খোঁজে। দুটি half-open পরিসর [s₁, e₁) আর [s₂, e₂) ছেদ করে ঠিক তখন, যখন s₁ < e₂ এবং s₂ < e₁. প্রমাণ: ছেদ করে না মানে একটি অন্যটির পুরো আগে শেষ, অর্থাৎ e₁ ≤ s₂ অথবা e₂ ≤ s₁; De Morgan-এর নিয়মে এর বিপরীতই শর্তটি। পরপর দুটি slot (৫:০০–৫:১৫ আর ৫:১৫–৫:৩০) ছোঁয়, কিন্তু ছেদ করে না:

-- রোগী ৫০: ৫ নভেম্বর বিকেল ৫টায় Dr. Tanvir Ahmed-এর slot 153-এ
INSERT INTO appointments (slot_id, patient_id, booked_at)
VALUES (153, 50, '2026-11-04 11:00:00');
-- overlap-এর শর্ত: a.start < b.end AND b.start < a.end
SELECT b.slot_id, b.doctor_id, b.slot_start, b.slot_end,
       a.slot_start < b.slot_end AND b.slot_start < a.slot_end AS overlaps
FROM slots a, slots b WHERE a.slot_id = 153 AND b.slot_id IN (193, 34);
-- একই সময়ে Dr. Sharmin Akter-এর খালি slot 193-এ একই রোগী
INSERT INTO appointments (slot_id, patient_id, booked_at)
VALUES (193, 50, '2026-11-04 11:05:00');

দুজন receptionist, শেষ slot — concurrency-র গল্প

এবার সবচেয়ে কঠিন প্রশ্ন: সত্যিকারের একসাথে চলা transaction-এ কী ঘটে (পর্ব ৪৪–৪৭)? সার্ভারটি PostgreSQL, ডিফল্ট READ COMMITTED. ৫ নভেম্বর সন্ধ্যা ৬টা; ধরুন ডা. শারমিনের অন্য খালি slot-গুলো এর মধ্যেই বুক হয়ে গেছে, বাকি শুধু slot ১৯৯ (৬:৩০)। কাউন্টার A আর কাউন্টার B একই মুহূর্তে দুজন রোগীকে বসাতে চান:

একই ঘটনা হাতে-কলমে, দুটি আলাদা connection দিয়ে — একটি ফাইলের SQLite ডেটাবেসে, দুই receptionist দুই connection. প্রথমবার unique index ছাড়া, দ্বিতীয়বার সহ:

import sqlite3, tempfile, os
def scenario(guard):
    path = os.path.join(tempfile.mkdtemp(), "clinic.db")
    with sqlite3.connect(path) as c:
        c.execute("CREATE TABLE appointments (appt_id INTEGER PRIMARY KEY, slot_id INT NOT NULL,"
                  " patient_id INT NOT NULL, status TEXT NOT NULL DEFAULT 'booked')")
        if guard:
            c.execute("CREATE UNIQUE INDEX one_active ON appointments(slot_id) WHERE status <> 'cancelled'")
    desk_a, desk_b = sqlite3.connect(path), sqlite3.connect(path)   # two receptionists
    free = "SELECT NOT EXISTS (SELECT 1 FROM appointments WHERE slot_id = 199 AND status <> 'cancelled')"
    print("A checks: free =", desk_a.execute(free).fetchone()[0] == 1)
    print("B checks: free =", desk_b.execute(free).fetchone()[0] == 1)
    for name, con, patient in (("A", desk_a, 11), ("B", desk_b, 12)):
        try:
            with con:                        # one transaction: commit or roll back
                con.execute("INSERT INTO appointments (slot_id, patient_id) VALUES (199, ?)", (patient,))
            print(f"{name} books patient {patient}: OK")
        except sqlite3.IntegrityError as e:
            print(f"{name} books patient {patient}: REJECTED ({e})")
    print("active bookings for slot 199:", desk_a.execute("SELECT COUNT(*) FROM appointments").fetchone()[0])
for guard in (False, True):
    print("--- unique index:", "yes" if guard else "no")
    scenario(guard)

--- unique index: no
A checks: free = True
B checks: free = True
A books patient 11: OK
B books patient 12: OK
active bookings for slot 199: 2
--- unique index: yes
A checks: free = True
B checks: free = True
A books patient 11: OK
B books patient 12: REJECTED (UNIQUE constraint failed: appointments.slot_id)
active bookings for slot 199: 1

Trigger কেন যথেষ্ট নয় — PostgreSQL-এ। R2-এর trigger-টি নিজেও একটি check-then-act: “এই রোগীর ছেদ করা appointment আছে কি?” দেখে তারপর লেখা। SQLite-এ একসাথে একটিই লেখক (writer) চলে, তাই সেখানে এটি নিরাপদ। কিন্তু PostgreSQL-এ READ COMMITTED-এ দুটি transaction একই রোগীকে দুই ডাক্তারের কাছে একই সময়ে বসালে দুটি trigger-ই অন্যটির uncommitted সারি দেখে না — দুটিই পাস, নিয়ম ভাঙে। তিনটি সঠিক সমাধান: (১) SERIALIZABLE isolation — PostgreSQL-এর SSI একটি transaction-কে 40001 serialization failure দিয়ে ফেরায়, অ্যাপ retry করে; (২) রোগীর সারিতে আগে SELECT … FOR UPDATE — একই রোগীর বুকিংগুলো লাইনে দাঁড়ায় (পর্ব ৪৬); (৩) সবচেয়ে ভালো, নিয়মটিকে constraint বানানো — exclusion constraint:

CREATE EXTENSION IF NOT EXISTS btree_gist;
CREATE TABLE slots (
  slot_id   bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  doctor_id int NOT NULL REFERENCES doctors ON DELETE RESTRICT,
  during    tstzrange NOT NULL,              -- [শুরু, শেষ) — half-open
  UNIQUE (slot_id, during),
  EXCLUDE USING gist (doctor_id WITH =, during WITH &&)  -- একই ডাক্তারের slot ছেদ নয়
);
CREATE TABLE appointments (
  appt_id    bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  slot_id    bigint NOT NULL,
  during     tstzrange NOT NULL,             -- slot-এর সময়ের কপি…
  patient_id bigint NOT NULL REFERENCES patients,
  status     text NOT NULL DEFAULT 'booked',
  FOREIGN KEY (slot_id, during) REFERENCES slots (slot_id, during),  -- …যা ভুল হতে পারে না
  EXCLUDE USING gist (patient_id WITH =, during WITH &&) WHERE (status <> 'cancelled')
);
CREATE UNIQUE INDEX appt_one_active_per_slot ON appointments (slot_id) WHERE status <> 'cancelled';

&& হলো range-এর ছেদ অপারেটর; exclusion constraint নিশ্চিত করে কোনো দুটি সক্রিয় সারিতে একই রোগী আর ছেদ করা সময় একসাথে থাকবে না — আর unique index-এর মতোই একসাথে চলা transaction-এর মধ্যে সঠিক থাকে। দাম একটি ইচ্ছাকৃত denormalization: সময়ের কপি appointments-এ। কপিটি ভুল হতে পারে না, কারণ composite foreign key (slot_id, during) তাকে slots-এর আসল মানের সাথে বেঁধে রাখে। MySQL-এ partial index নেই; প্রচলিত বিকল্প একটি generated column (সক্রিয় হলে slot_id, নইলে NULL) আর তার ওপর UNIQUE — InnoDB-র UNIQUE একাধিক NULL মেনে নেয়।

৭ · Index — প্রধান কোয়েরির plan, আগে আর পরে

পর্ব ৪১-এর নিয়ম: index বানানো হয় কোয়েরির জন্য, কলামের জন্য নয়। আমাদের প্রধান কোয়েরি আর তাদের দরকার:

-- আগে: রোগীর ইতিহাস আর দৈনিক আয়
EXPLAIN QUERY PLAN SELECT appt_id, slot_id FROM appointments WHERE patient_id = 7;
EXPLAIN QUERY PLAN SELECT method, SUM(amount) FROM payments
WHERE paid_at >= '2026-11-03' AND paid_at < '2026-11-04' GROUP BY method;
-- দুটি index
CREATE INDEX appt_patient ON appointments(patient_id);
CREATE INDEX pay_day ON payments(paid_at, method, amount);
-- পরে: একই দুটি কোয়েরি
EXPLAIN QUERY PLAN SELECT appt_id, slot_id FROM appointments WHERE patient_id = 7;
EXPLAIN QUERY PLAN SELECT method, SUM(amount) FROM payments
WHERE paid_at >= '2026-11-03' AND paid_at < '2026-11-04' GROUP BY method;
-- খালি slot-এর কোয়েরি: index আগে থেকেই আছে
EXPLAIN QUERY PLAN SELECT s.slot_id FROM slots s
WHERE s.doctor_id = 5 AND s.slot_start >= '2026-11-05' AND s.slot_start < '2026-11-06'
  AND NOT EXISTS (SELECT 1 FROM appointments a WHERE a.slot_id = s.slot_id AND a.status <> 'cancelled');

খরচের হিসাব: n সারির টেবিলে SCAN মানে n সারি পড়া, O(n); B+ tree-তে SEARCH মানে গাছের উচ্চতা ধরে নামা আর k-টি মিল পড়া, O(log n + k) (পর্ব ৪০)। ১৭৭ সারিতে পার্থক্য চোখে পড়ে না; কিন্তু পাঁচ বছরে ক্লিনিকে কয়েক লাখ appointment হলে রোগীর ইতিহাস খোলায় লাখো সারি বনাম কয়েকটি page — আর R2-এর trigger প্রতিটি বুকিংয়ে এই একই খোঁজ চালায়, তাই appt_patient বুকিংকেও দ্রুত রাখে। উল্টো দিকে, প্রতিটি index প্রতিটি INSERT-এ একটি বাড়তি B+ tree লেখা। এখানে লেখা কম (দিনে কয়েকশো বুকিং), পড়া বেশি — দুটি নতুন index স্পষ্টতই লাভজনক।

৮ · নিরাপত্তা — role, view আর audit trigger

রোগীর রোগনির্ণয় আর ওষুধ ব্যক্তিগত তথ্যের মধ্যে সবচেয়ে সংবেদনশীলগুলোর একটি। নীতি পর্ব ৫১-এর least privilege: প্রতিটি ভূমিকা ঠিক ততটুকু পায়, যতটুকু তার কাজে লাগে।

CREATE ROLE receptionist NOLOGIN;  CREATE ROLE doctor NOLOGIN;
GRANT SELECT, INSERT ON patients, appointments, payments TO receptionist;
GRANT UPDATE (status, cancelled_at) ON appointments TO receptionist;
GRANT SELECT ON doctor_schedule TO doctor;      -- view, মূল টেবিল নয়
GRANT SELECT, INSERT, UPDATE ON prescriptions, prescription_items TO doctor;
REVOKE ALL ON payments FROM doctor;
-- প্রতিটি ডাক্তার শুধু নিজের রোগীর prescription
ALTER TABLE prescriptions ENABLE ROW LEVEL SECURITY;
CREATE POLICY own_patients ON prescriptions TO doctor USING (appt_id IN (
  SELECT a.appt_id FROM appointments a JOIN slots s USING (slot_id)
  WHERE s.doctor_id = current_setting('app.doctor_id')::int));
CREATE ROLE dr_sharmin LOGIN PASSWORD '…' IN ROLE doctor;

এখানে role দলগত অনুমতির নাম, আর প্রতিটি মানুষের নিজস্ব login role তার সদস্য — কে কী করলেন, audit-এ আলাদা দেখা যায়। Row-level security সারির স্তরে ছাঁকে; app.doctor_id অ্যাপ প্রতিটি connection-এ বসায়। এবার SQLite-এ চালানো যায় এমন দুটি অংশ — ডাক্তারের view আর prescription-এর audit (R6, R7):

-- ডাক্তারদের জন্য view: রোগী আর সময় আছে, টাকা আর ফোন নেই
CREATE VIEW doctor_schedule AS
SELECT s.doctor_id, s.slot_start, a.appt_id, p.name AS patient, p.birth_year, a.status
FROM slots s JOIN appointments a ON a.slot_id = s.slot_id AND a.status <> 'cancelled'
JOIN patients p ON p.patient_id = a.patient_id;
SELECT time(slot_start) AS at, patient, birth_year, status FROM doctor_schedule
WHERE doctor_id = 5 AND slot_start >= '2026-11-05' ORDER BY slot_start;
-- prescription-এর প্রতিটি সংশোধন audit টেবিলে; মুছে ফেলা নিষেধ
CREATE TABLE rx_audit (audit_id INTEGER PRIMARY KEY, rx_id INTEGER NOT NULL,
  old_diagnosis TEXT, new_diagnosis TEXT, changed_at TEXT DEFAULT CURRENT_TIMESTAMP);
CREATE TRIGGER rx_audit_upd AFTER UPDATE ON prescriptions BEGIN
  INSERT INTO rx_audit (rx_id, old_diagnosis, new_diagnosis)
  VALUES (OLD.rx_id, OLD.diagnosis, NEW.diagnosis); END;
CREATE TRIGGER rx_no_delete BEFORE DELETE ON prescriptions BEGIN
  SELECT RAISE(ABORT, 'prescriptions are never deleted - write a correction'); END;
UPDATE prescriptions SET diagnosis = 'Peptic ulcer disease' WHERE rx_id = 2;
SELECT rx_id, old_diagnosis, new_diagnosis FROM rx_audit;
DELETE FROM prescriptions WHERE rx_id = 2;

বাকি স্তরগুলো (defense in depth): অ্যাপে সব কোয়েরি parameterised — রোগীর নাম বা ফোন কখনো SQL-এর লেখায় জোড়া হয় না (পর্ব ৪৯, ৫১); অ্যাপ আর ডেটাবেসের মাঝে TLS; ডিস্ক আর backup এনক্রিপ্টেড; staging-এ আসল রোগীর ডেটা নয়, মুখোশ পরানো (masked) বা নমুনা ডেটা; আর ডেটাবেসের port ইন্টারনেটে খোলা নয়, শুধু অ্যাপ সার্ভার থেকে।

৯ · পরিচালনা আর deployment — backup, monitoring, migration আর কোথায় চালাবেন

Backup আর PITR — RPO ৫ মিনিট, RTO ১ ঘণ্টা

অংশ ১-এর অ-কার্যকরী প্রয়োজন দুটি এখন সংখ্যা: RPO ≤ ৫ মিনিট, RTO ≤ ১ ঘণ্টা (পর্ব ৫২)। শুধু রাতের backup দিয়ে RPO হয় প্রায় ২৪ ঘণ্টা — সন্ধ্যা ৭টায় ডিস্ক নষ্ট হলে সেদিনের সব বুকিং আর পেমেন্ট হারায়। তাই পরিকল্পনা:

• প্রতি রাতে base backup (pgBackRest বা managed সেবার স্বয়ংক্রিয় backup), ৩০ দিন রাখা, আরেকটি অঞ্চলে কপি — 3-2-1 নিয়ম।
• ধারাবাহিক WAL archiving, archive_timeout = 60s: লেখা কম হলেও প্রতি মিনিটে WAL ফাইল archive-এ যায়। ফলে প্রায় যেকোনো মুহূর্তে ফেরা যায় — PITR (পর্ব ৪৮)। সবচেয়ে খারাপ ক্ষতি মোটামুটি শেষ archive-এর পরের ১ মিনিট, ৫ মিনিটের লক্ষ্যের মধ্যে।
• RTO-র হিসাব: ধরা পড়া (১০ মিনিট, alert থেকে) + নতুন সার্ভারে base backup ফেরানো (ধরা যাক ২০ মিনিট) + WAL replay (১৫ মিনিট) + যাচাই আর অ্যাপ ঘোরানো (১০ মিনিট) ≈ ৫৫ মিনিট। সংখ্যাগুলো অনুমান নয় — প্রতি মাসে একবার সত্যিই restore করে মাপা হয়। আরও কম RTO চাইলে একটি hot standby replica আর failover.

Monitoring আর migration

ক্লিনিকের জন্য অর্থপূর্ণ মাপ (পর্ব ৫৩): বুকিংয়ের p95 latency; ঘণ্টায় কতগুলো 23505 (বেশি হলে একই slot নিয়ে প্রতিযোগিতা — হয়তো জনপ্রিয় ডাক্তারের আরও slot লাগবে); সবচেয়ে নতুন backup কত পুরোনো; WAL archive ব্যর্থ হচ্ছে কি না; ডিস্কের বৃদ্ধি; ব্যর্থ login. প্রতিটির একটি alert আর একটি করণীয়।

Schema কখনো হাতে বদলানো হয় না। প্রতিটি পরিবর্তন একটি সংস্করণ-নম্বরযুক্ত migration ফাইল (Flyway, Liquibase বা Alembic), Git-এ, review-এর পর (পর্ব ৫০)। ধরুন ক্লিনিক “ভিডিও কনসালটেশন” চালু করবে। expand–contract ধাপে: (১) ALTER TABLE slots ADD COLUMN mode text NOT NULL DEFAULT 'in_person' CHECK (mode IN ('in_person', 'video')) — পুরোনো কোড চলতেই থাকে; (২) নতুন অ্যাপ mode পড়ে আর লেখে; (৩) পরে, দরকার হলে পুরোনো ধারণা সরানো। প্রতিটি ধাপ আলাদা release, প্রতিটি ফিরিয়ে নেওয়া যায়।

কোথায় চালাবেন — managed PostgreSQL বনাম নিজের VPS

Region: বড় cloud প্রদানকারীদের নিকটতম region সাধারণত সিঙ্গাপুর বা ভারতে (মুম্বাই)। ঢাকা থেকে সেখানে প্রতিটি round trip কয়েক দশক মিলিসেকেন্ড — একটি বুকিংয়ে ৫–১০টি কোয়েরি হলে চোখে পড়ার মতো, তাই অ্যাপ সার্ভার আর ডেটাবেস একই region-এ রাখুন, আর কোয়েরির সংখ্যা কম। স্বাস্থ্য-তথ্য দেশের বাইরে রাখা যাবে কি না (data residency) — এ বিষয়ে বাংলাদেশের নিয়মকানুন বদলাচ্ছে; চালুর আগে সর্বশেষ আইন আর প্রয়োজনে আইনজীবীর পরামর্শ নিন, অনুমানে নয়। এক শাখার ছোট ক্লিনিকের জন্য একটি যুক্তিসংগত শুরু: একটি managed PostgreSQL, স্বয়ংক্রিয় backup আর PITR চালু, একটি ছোট instance — আর পরিস্থিতি বদলালে migration-এর পথ খোলা।

Release checklist — প্রতিটি পরিবর্তনের পথ

নিচে একটি smoke test-এর ছোট রূপ: schema বানানো, recursive CTE-তে seed, double booking-এর চেষ্টা, বাতিল slot আবার বুক, আর আয়ের রিপোর্ট মেলানো। CI pipeline-এ প্রতিটি migration-এর পর এমন একটি স্ক্রিপ্ট চলে:

import sqlite3
db = sqlite3.connect(":memory:", autocommit=True); db.execute("PRAGMA foreign_keys = ON")
db.executescript("""
CREATE TABLE doctors (doctor_id INTEGER PRIMARY KEY, fee INT NOT NULL CHECK (fee > 0));
CREATE TABLE slots (slot_id INTEGER PRIMARY KEY, doctor_id INT NOT NULL REFERENCES doctors,
  slot_start TEXT NOT NULL, UNIQUE (doctor_id, slot_start));
CREATE TABLE appointments (appt_id INTEGER PRIMARY KEY, slot_id INT NOT NULL REFERENCES slots,
  patient_id INT NOT NULL, status TEXT NOT NULL DEFAULT 'booked');
CREATE UNIQUE INDEX one_active ON appointments(slot_id) WHERE status <> 'cancelled';
CREATE TABLE payments (appt_id INT NOT NULL REFERENCES appointments, amount INT NOT NULL,
  method TEXT NOT NULL CHECK (method IN ('bkash', 'cash')));
INSERT INTO doctors VALUES (1, 800), (2, 1000);
WITH RECURSIVE n(i) AS (SELECT 0 UNION ALL SELECT i + 1 FROM n WHERE i < 15)
INSERT INTO slots (doctor_id, slot_start)
SELECT i / 8 + 1, datetime('2026-11-01 17:00', '+' || (i % 8 * 15) || ' minutes') FROM n;
INSERT INTO appointments (slot_id, patient_id) SELECT slot_id, slot_id FROM slots WHERE slot_id % 3 <> 0;
""")
def rejected(sql):
    try: db.execute(sql); return False
    except sqlite3.IntegrityError: return True
checks = {"16 slots seeded": db.execute("SELECT COUNT(*) FROM slots").fetchone()[0] == 16,
          "double booking rejected": rejected("INSERT INTO appointments (slot_id, patient_id) VALUES (1, 99)")}
db.execute("UPDATE appointments SET status = 'cancelled' WHERE slot_id = 2")
checks["cancelled slot can be rebooked"] = not rejected("INSERT INTO appointments (slot_id, patient_id) VALUES (2, 77)")
db.execute("""INSERT INTO payments SELECT a.appt_id, d.fee, CASE a.appt_id % 2 WHEN 0 THEN 'bkash' ELSE 'cash' END
  FROM appointments a JOIN slots s USING (slot_id) JOIN doctors d USING (doctor_id) WHERE a.status <> 'cancelled'""")
report = db.execute("SELECT method, COUNT(*), SUM(amount) FROM payments GROUP BY method").fetchall()
checks["revenue = 6 x 800 + 5 x 1000"] = sum(r[2] for r in report) == 9800
for name, ok in checks.items(): print(f"[{'PASS' if ok else 'FAIL'}] {name}")
print("daily report 2026-11-01:", report)
print("all checks passed" if all(checks.values()) else "SOME CHECKS FAILED")

[PASS] 16 slots seeded
[PASS] double booking rejected
[PASS] cancelled slot can be rebooked
[PASS] revenue = 6 x 800 + 5 x 1000
daily report 2026-11-01: [('bkash', 5, 4400), ('cash', 6, 5400)]
all checks passed

১০ · AI-এর যুগে ডিজাইন — আর এরপর কোথায়

“একটি ক্লিনিক appointment সিস্টেমের schema দাও” — AI কয়েক সেকেন্ডে সুন্দর CREATE TABLE দেবে। সাধারণত সেটি চলে; প্রশ্ন হলো নিয়মগুলো রক্ষা করে কি না। এই ধরনের কাজে AI-এর প্রচলিত ভুল:

AI-এর schema চালুর আগে — চেকলিস্ট

• প্রতিটি ব্যবসার নিয়মের পাশে তার রক্ষক (constraint/index/trigger) লেখা আছে
• প্রতিটি নিয়ম ভাঙার একটি INSERT চালিয়ে দেখেছি — সত্যিই ব্যর্থ হয়
• দুটি connection-এ একসাথে বুকিংয়ের পরীক্ষা করেছি
• বাতিল, NULL আর duplicate-সহ নমুনা ডেটায় প্রতিটি কোয়েরির সারির সংখ্যা মিলিয়েছি
• প্রধান কোয়েরিগুলোর EXPLAIN দেখেছি; টাকা আর সময়ের টাইপ যাচাই করেছি
• প্রতিটি foreign key-র ON DELETE সচেতনভাবে বাছা

এরপর কোথায় — মডিউল ১০ আর আপনার নিজের প্রজেক্ট

এই একটি সিস্টেমে কোর্সের প্রায় প্রতিটি মডিউল কাজে লেগেছে: ER আর mapping (মডিউল ২), SQL (৩–৪), FD আর normal form (৫), index (৬), transaction (৭), নিরাপত্তা আর পরিচালনা (৮), cloud (৯)। এখন পরীক্ষা আর ইন্টারভিউর জন্য একই জ্ঞানকে দ্রুত ব্যবহারের অনুশীলন:

• পর্ব ৬৩ · SQL output prediction — এই পর্বের মতো কোয়েরির ফল হাতে বের করা।
• পর্ব ৬৪ · MCQ প্রশ্নব্যাংক আর পর্ব ৬৫ · লিখিত ও ভাইভা — normalization-এর প্রমাণ, ACID, isolation.
• পর্ব ৬৬ · SQL ইন্টারভিউর সমস্যা — anti-join, window, top-N-এর প্যাটার্ন।
• পর্ব ৬৭ · ডেটাবেস ডিজাইন ইন্টারভিউ — “একটি বুকিং সিস্টেম ডিজাইন করুন” ঠিক এই পর্বের প্রশ্ন।

নিজের প্রজেক্টের জন্য কয়েকটি বিস্তার: অপেক্ষমাণ তালিকা (waitlist) — slot বাতিল হলে প্রথমজনকে স্বয়ংক্রিয় প্রস্তাব; SMS reminder-এর জন্য outbox টেবিল; একাধিক শাখা — প্রতিটি টেবিলে branch_id আর row-level security; আর মাসিক রিপোর্টের জন্য একটি ছোট data warehouse (পর্ব ৫৫)। অথবা একই পদ্ধতিতে সম্পূর্ণ আলাদা একটি সিস্টেম — যেমন বাসের টিকিট বুকিং, যেখানে slot-এর জায়গায় “যাত্রা × আসন”.