ফাইল সিস্টেম বনাম DBMS — ইতিহাস আর সমস্যা

১ · DBMS-এর আগে — খাতা, কার্ড আর ফাইল

পাড়ার মুদি দোকানের বাকির খাতার কথা ভাবুন। প্রতিটি পাতায় একজন গ্রাহক, তারিখ ধরে লেখা কে কত টাকার জিনিস নিলেন। দোকানদার নিজেই লেখেন, নিজেই পড়েন। একজন মানুষ, একটি খাতা — কোনো সমস্যা নেই।

এবার ভাবুন দোকানটি বড় হলো। তিনজন কর্মচারী, দুটি ক্যাশ কাউন্টার, একটি গুদাম। গুদামের খাতা আলাদা, ক্যাশের খাতা আলাদা, বাকির খাতা আলাদা। মাস শেষে মালিক জানতে চাইলেন, “কোন পণ্য সবচেয়ে বেশি বিক্রি হলো, আর কোন গ্রাহকের বাকি সবচেয়ে বেশি?” উত্তর বের করতে কাউকে পুরো একটা দিন তিনটি খাতা পাশাপাশি রেখে মেলাতে হবে।

কম্পিউটার আসার পর প্রথম কয়েক দশকে প্রতিষ্ঠানগুলো ঠিক এই খাতাগুলোকেই কম্পিউটারে তুলেছিল — কাগজের বদলে flat file. Flat file মানে সাধারণ একটি ফাইল, যার প্রতিটি লাইনে একটি রেকর্ড; ফাইলের ভেতরে কোন অংশের কী মানে, তা লেখা থাকে না — জানে শুধু সেই ফাইল পড়ার প্রোগ্রাম।

এই যুগের প্রধান ভাষা ছিল COBOL (COmmon Business-Oriented Language), যা ১৯৫৯ সালে একটি কমিটি তৈরি করে; এতে Grace Hopper-এর আগের কাজের বড় প্রভাব ছিল। COBOL প্রোগ্রামের শুরুতেই থাকে ফাইলের বর্ণনা — কোন রেকর্ডে কত অক্ষরের কোন ঘর। অর্থাৎ ডেটার গঠন লেখা থাকত প্রোগ্রামের ভেতরে, ডেটার সাথে নয়। এই একটি সিদ্ধান্ত থেকেই পরের সব সমস্যার জন্ম।

পর্ব ০১-এ দেখেছেন ডেটা, তথ্য আর database বলতে কী বোঝায়। এই পর্বে প্রশ্ন একটাই — ফাইলেই তো ডেটা রাখা যায়, তাহলে আলাদা একটি DBMS-এর দরকার পড়ল কেন? উত্তর পেতে একটি গল্প ধরে এগোই।

২ · একটি কোচিং সেন্টারের গল্প — তিন অফিস, তিন ফাইল

রাজশাহীর একটি কোচিং সেন্টার, নাম ধরুন “আলোকিত কোচিং”। প্রায় ছয়শো শিক্ষার্থী। শুরুতে মালিক নিজেই সব খাতায় লিখতেন। পরে কম্পিউটার কেনা হলো, আর তিনটি অফিস যার যার মতো ফাইল বানাল:

• ভর্তি অফিস — একটি Excel ফাইলে রোল, নাম, অভিভাবকের নাম, ফোন, ঠিকানা।
• হিসাব অফিস — একজন প্রোগ্রামার বন্ধুর বানানো ছোট একটি প্রোগ্রাম, যা একটি text ফাইলে নির্দিষ্ট দৈর্ঘ্যের ঘরে রোল, নাম, ফোন আর মাসিক ফি রাখে।
• পরীক্ষা অফিস — একটি CSV ফাইল (কমা দিয়ে আলাদা করা ঘর), যেখানে রোল, নাম, ফোন আর প্রতিটি পরীক্ষার নম্বর।

তিনটি ফাইলের ভেতরটা দেখুন — একই শিক্ষার্থী, তিন রকম চেহারা:

Roll | Name        | Guardian      | Phone       | Address
101  | Rafi Ahmed  | Kamal Ahmed   | 01711111111 | Shaheb Bazar
102  | Mim Akter   | Rokeya Begum  | 01822222222 | Uposhohor

0101Rafi Ahmed          01711111111001500
0102Mim Akter           01822222222001500

roll,name,phone,mock1,mock2
101,Rafi Ahmed,01711111111,72,81
102,Mim Akhter,01822222222,88,79

প্রথম কয়েক মাস সব ঠিকঠাক চলল। তারপর একে একে সমস্যা দেখা দিতে লাগল। শিক্ষার্থীর সংখ্যা বাড়ল, অফিস বাড়ল, প্রশ্ন বাড়ল। এই সমস্যাগুলোই ডেটাবেসের পাঠ্যবইয়ে “file processing system-এর অসুবিধা” নামে পরিচিত — বিশ্ববিদ্যালয়, চাকরি বা ইন্টারভিউর পরীক্ষায় বারবার আসে। আমরা একটি একটি করে দেখব, প্রতিটি এই কোচিং সেন্টারেই।

৩ · সমস্যা ১ — একই ডেটার অনেক কপি, আর কপিগুলোর অমিল

রাফির ফোন নম্বর তিনটি ফাইলে আছে। একই তথ্যের একাধিক জায়গায় থাকাকে বলে data redundancy (ডেটার পুনরাবৃত্তি)। শুধু জায়গা নষ্ট হলে সমস্যা ছোট ছিল। বড় সমস্যা হয় যখন কপিগুলো বদলাতে গিয়ে একটি বদলায়, বাকিগুলো বদলায় না — তখন একই প্রশ্নের দুটি ভিন্ন উত্তর পাওয়া যায়। একে বলে data inconsistency (অসংগতি)। নিচের ডায়াগ্রামে ধাপে ধাপে দেখুন:

এবার নিজের হাতে অমিল খুঁজে দেখুন। ধরুন ভর্তি অফিস আর পরীক্ষা অফিসের ফাইল দুটিকে আমরা দুটি টেবিলে তুলে আনলাম: admission_file আর exam_file, দুটোতেই তিনটি কলাম — roll (রোল), name (নাম), phone (ফোন)। নিচের কোয়েরি প্রতিটি রোল দুই টেবিলে মিলিয়ে দেখায় কোথায় নাম বা ফোন আলাদা। কোয়েরির খুঁটিনাটি (JOIN) পর্ব ১৯-এ শিখবেন; এখন শুধু ফলাফলটি দেখুন।

-- দুই অফিসের কপি মিলিয়ে অমিল খোঁজা
SELECT a.roll,
       a.name  AS admission_name,
       e.name  AS exam_name,
       a.phone AS admission_phone,
       e.phone AS exam_phone
FROM admission_file a
JOIN exam_file e ON a.roll = e.roll
WHERE a.phone <> e.phone OR a.name <> e.name;

৪ · সমস্যা ২, ৩ ও ৪ — নতুন প্রশ্ন, ভিন্ন ফরম্যাট, লুকানো নিয়ম

সমস্যা ২ · ডেটা পাওয়া কঠিন — প্রতিটি নতুন প্রশ্নে নতুন প্রোগ্রাম

এক সোমবার পরিচালক জানতে চাইলেন, “যাদের দুই মাসের ফি বাকি, অথচ mock পরীক্ষায় ৮০-র বেশি পেয়েছে, তাদের তালিকা দিন — বৃত্তির কথা ভাবছি।” ডেটা সবই আছে, কিন্তু কোনো প্রোগ্রাম এই প্রশ্নের উত্তর দেয় না। হিসাবের প্রোগ্রাম শুধু ফি-র রিপোর্ট ছাপে, পরীক্ষার প্রোগ্রাম শুধু মেধাতালিকা। প্রোগ্রামার বন্ধুকে ফোন করা হলো; তিনি বললেন, “বৃহস্পতিবার নাগাদ লিখে দেব।” তাঁকে যা লিখতে হবে, তার কাঠামো মোটামুটি এরকম:

// ফাইল-ভিত্তিক ব্যবস্থায় একটি নতুন প্রশ্নের প্রোগ্রাম
open "accounts.txt"
for each line:
    roll   = line[0..3]          // প্রথম ৪ অক্ষর
    due    = line[35..40]        // ঘরের অবস্থান জানতে হবে
    if due >= 2 months fee: remember roll in DUE_LIST
open "exam.csv"
for each line:
    split by ","                 // ভিন্ন ফরম্যাট, ভিন্ন নিয়ম
    if roll in DUE_LIST and max(mock1, mock2) > 80:
        print roll, name

পরের সপ্তাহে প্রশ্ন একটু বদলাল — “শুধু উপশহরের শিক্ষার্থীদের মধ্যে।” এবার ঠিকানা আছে তৃতীয় ফাইলে, তাই আবার নতুন প্রোগ্রাম। ফাইল-ভিত্তিক ব্যবস্থায় প্রতিটি নতুন প্রশ্ন মানে একটি নতুন প্রোগ্রাম, আর প্রতিটি প্রোগ্রামে নতুন বাগের সুযোগ। পূর্বপরিকল্পনা ছাড়া হঠাৎ করা প্রশ্নকে বলে ad-hoc query; বাস্তবে ব্যবসার বেশিরভাগ প্রশ্নই এমন।

সমস্যা ৩ · ডেটা বিচ্ছিন্ন — ভিন্ন ভিন্ন ফরম্যাট

উপরের প্রোগ্রামে খেয়াল করুন — একটি ফাইল পড়তে হচ্ছে অক্ষরের অবস্থান গুনে, আরেকটি কমা ধরে ভেঙে, তৃতীয়টি Excel-এর নিজস্ব ফরম্যাটে। ডেটা ছড়িয়ে আছে আলাদা আলাদা ফাইলে, আলাদা ফরম্যাটে, কখনো আলাদা কম্পিউটারে। একে বলে data isolation. রোল নম্বরও এক রকম নয় — হিসাবের ফাইলে 0101, বাকি দুটিতে 101; মেলাতে গেলে আগে রূপান্তর করতে হবে। নামের বানান আলাদা হলে নাম দিয়ে মেলানো অসম্ভব।

সমস্যা ৪ · Integrity-র সমস্যা — নিয়মগুলো কোডের ভেতরে লুকানো

কোচিং সেন্টারের কিছু নিয়ম আছে: মাসিক ফি শূন্য বা ঋণাত্মক হতে পারবে না; পরীক্ষার নম্বর ০ থেকে ১০০-র মধ্যে; যে রোল ভর্তি অফিসে নেই, তার নামে ফি জমা নেওয়া যাবে না। এ ধরনের নিয়মকে বলে integrity constraint — ডেটা “সঠিক” থাকার শর্ত।

ফাইল-ভিত্তিক ব্যবস্থায় এই নিয়ম কোথায় থাকে? প্রতিটি প্রোগ্রামের ভেতরে, if হিসেবে। হিসাবের প্রোগ্রামে হয়তো ফি যাচাই আছে, কিন্তু যিনি Excel-এ সরাসরি ফি বদলান, তাঁকে কেউ আটকায় না। নতুন একটি নিয়ম এলে (“ফি কমপক্ষে ৫০০ টাকা”) সব প্রোগ্রাম খুঁজে খুঁজে বদলাতে হয় — একটি বাদ পড়লেই ভুল ডেটা ঢুকে যায়। আর পাঁচ বছর পর কেউ জানবেই না কোন নিয়ম কোন প্রোগ্রামে লেখা ছিল।

৫ · সমস্যা ৫, ৬ ও ৭ — অর্ধেক কাজ, একসাথে দুজন, আর নিরাপত্তা

সমস্যা ৫ · Atomicity-র সমস্যা — কাজ অর্ধেক হয়ে থেমে গেলে

কিছু কাজ আছে যা হয় পুরোটা হবে, নয়তো একটুও হবে না — মাঝামাঝি কোনো অবস্থা গ্রহণযোগ্য নয়। এই গুণের নাম atomicity. সবচেয়ে পরিচিত উদাহরণ টাকা পাঠানো: করিমের হিসাব থেকে ৫০০০ টাকা কাটা আর সেলিনার হিসাবে ৫০০০ টাকা যোগ — দুটি আলাদা লেখা, কিন্তু একসাথে একটি কাজ। কোচিং সেন্টারের হিসাব অফিসে ধরুন এমন দুটি হিসাব ফাইলে রাখা আছে। এবার দেখুন লোডশেডিং ঠিক ভুল মুহূর্তে এলে কী হয়:

1// transfer: Karim -> Selina, 50002a = read("karim.dat")3a = a - 50004write("karim.dat", a)5b = read("selina.dat")6b = b + 50007write("selina.dat", b)

সমস্যা ৬ · একসাথে দুজন — concurrent access-এর গোলমাল

কোচিং সেন্টারে দুটি কাউন্টার। রাফির অভিভাবক ১ নম্বর কাউন্টারে অগ্রিম ৩০০০ টাকা জমা দিলেন, আর ঠিক একই সময়ে ২ নম্বর কাউন্টারে ক্লার্ক রাফির অগ্রিম থেকে ২০০০ টাকা মাসিক ফি কাটলেন। শুরুতে অগ্রিম ছিল ১০০০০, তাই সঠিক ফল ১০০০০ + ৩০০০ − ২০০০ = ১১০০০. দুজনের প্রোগ্রামই একই ফাইল পড়ে আর লেখে, কেউ কারও কথা জানে না। একাধিক জনের একই ডেটায় একসাথে কাজ করাকে বলে concurrent access, আর তাদের সমন্বয়ের ব্যবস্থাকে বলে concurrency control. সমন্বয় না থাকলে কী হয় দেখুন:

এই উদাহরণে মাত্র দুটি কাউন্টার। কিন্তু ট্রেনের টিকিট বুকিং বা bKash-এর মতো ব্যবস্থায় একই মুহূর্তে হাজার হাজার মানুষ একই ডেটায় হাত দেন — শেষ সিটটি দুজনকে বিক্রি হয়ে যাওয়া, বা একই টাকা দুবার খরচ হয়ে যাওয়া ঠিক এই ধরনের সমস্যা। Transaction, lock, schedule আর isolation level নিয়ে পুরো মডিউল ৭ আছে — বিশেষ করে পর্ব ৪৫ থেকে ৪৭.

সমস্যা ৭ · নিরাপত্তার সমস্যা — হয় পুরো ফাইল, নয়তো কিছুই না

পরীক্ষা অফিসের ক্লার্কের শুধু নাম আর নম্বর দেখার কথা, অভিভাবকের ফোন বা ফি নয়। কিন্তু অপারেটিং সিস্টেম অনুমতি দেয় পুরো ফাইলের ওপর — হয় ফাইলটি খুলতে পারবেন, নয়তো পারবেন না। “এই কলামগুলো দেখতে পারবেন, ওই কলাম নয়” বা “শুধু নিজের শাখার শিক্ষার্থী” বলার উপায় নেই। ফলে বাস্তবে সবাই সব ফাইলের কপি নিয়ে ঘোরেন — পেনড্রাইভে, ইমেইলে, মেসেঞ্জারে। কে কখন কী দেখল বা বদলাল, তার কোনো হিসাবও থাকে না।

৬ · DBMS কীভাবে প্রতিটি সমস্যার সমাধান করে

DBMS জাদু নয় — প্রতিটি সমস্যার জন্য একটি নির্দিষ্ট বৈশিষ্ট্য আছে। পুরো ছবিটি এক টেবিলে:

এবার এগুলো নিজের চোখে দেখুন। নিচের সব editor-এ একটি ছোট অনলাইন দোকানের নমুনা ডেটাবেস লোড হয় (পুরো কোর্সে এটিই ব্যবহার হবে)। এখানে আমাদের লাগবে দুটি টেবিল: customers — গ্রাহক (customer_id, name, city, phone, joined_on); আর products — পণ্য (product_id, name, category_id, price টাকায়, stock মজুত)। এ ছাড়া আছে orders (অর্ডার: কোন গ্রাহক, কোন তারিখ, অবস্থা) আর order_items (কোন অর্ডারে কোন পণ্য কতটি, কত দামে)। প্রতিটি editor-এর নিচে “নমুনা ডেটাবেস” খুলে সব সারি দেখতে পারবেন। কোড বদলালে ফলও সাথে সাথে বদলায়।

এক জায়গায় বদল — সবাই দেখে নতুন মান

গ্রাহক Rahim Uddin (customer_id 1) ঢাকা থেকে গাজীপুরে চলে গেছেন। তাঁর তিনটি অর্ডার আছে। ফাইল-ভিত্তিক ব্যবস্থায় হয়তো প্রতিটি অর্ডারের রেকর্ডে ঠিকানা কপি করা থাকত। এখানে শহর আছে শুধু customers টেবিলে, আর অর্ডারগুলো শুধু customer_id দিয়ে গ্রাহককে চেনে। একবার বদলান:

-- শহর বদলানো হলো একটিমাত্র সারিতে
UPDATE customers SET city = 'Gazipur' WHERE customer_id = 1;

-- এবার Rahim-এর সব অর্ডারের সাথে শহর দেখি
SELECT o.order_id, o.order_date, c.name, c.city
FROM orders o
JOIN customers c ON c.customer_id = o.customer_id
WHERE o.customer_id = 1;

নিয়ম ডেটাবেসে লেখা — ভুল ডেটা ঢোকেই না

নমুনা ডেটাবেসের products টেবিল তৈরির সময় লেখা হয়েছিল CHECK (price > 0) — দাম শূন্যের বেশি হতেই হবে। এবার কেউ ভুল করে শূন্য দামের একটি পণ্য ঢোকানোর চেষ্টা করছে। এই কোডটি ইচ্ছে করে error দেখানোর জন্য:

-- দাম 0 — নিয়ম ভাঙছে
INSERT INTO products (product_id, name, category_id, price, stock)
VALUES (111, 'Free Pen', 2, 0, 50);

শুধু একটি টেবিলের ভেতরের নিয়ম নয়, টেবিলের মধ্যের সম্পর্কও DBMS পাহারা দেয়। orders টেবিলের customer_id একটি foreign key — যে গ্রাহক নেই, তাঁর নামে অর্ডার হতে পারে না। নমুনা ডেটায় গ্রাহক মাত্র ৮ জন; ৯৯ নম্বর গ্রাহকের নামে অর্ডার ঢোকানোর চেষ্টা দেখুন (এটিও ইচ্ছাকৃত error):

-- 99 নম্বর গ্রাহক নেই
INSERT INTO orders (order_id, customer_id, order_date, status)
VALUES (1011, 99, '2025-10-20', 'pending');

নতুন প্রশ্ন — নতুন প্রোগ্রাম ছাড়াই

মনে আছে পরিচালকের প্রশ্নে প্রোগ্রামারের লেগেছিল তিন দিন? দোকানের মালিক হঠাৎ জানতে চাইলেন, “ঢাকার গ্রাহকদের নাম আর ফোন নম্বর দিন।” SQL-এ এটি একটি বাক্য:

SELECT name, phone
FROM customers
WHERE city = 'Dhaka';

এবার একটু কঠিন প্রশ্ন, যেটি ফাইল-ভিত্তিক ব্যবস্থায় তিনটি ফাইল মিলিয়ে লিখতে হতো: “বাতিল (cancelled) অর্ডার বাদ দিয়ে, কোন শহর থেকে কয়টি অর্ডার আর মোট কত টাকার বিক্রি?” কোয়েরির গঠন এখনই বোঝার দরকার নেই (GROUP BY আসবে পর্ব ১৮-এ) — শুধু দেখুন, পাঁচ লাইনে উত্তর:

SELECT c.city,
       COUNT(DISTINCT o.order_id)        AS orders,
       SUM(oi.quantity * oi.unit_price)  AS total_taka
FROM customers c
JOIN orders o       ON o.customer_id = c.customer_id
JOIN order_items oi ON oi.order_id   = o.order_id
WHERE o.status <> 'cancelled'
GROUP BY c.city
ORDER BY total_taka DESC;

Transaction — অর্ধেক কাজ ফিরিয়ে নেওয়া

টাকা পাঠানোর stepper-এ দেখেছিলেন, DBMS অসমাপ্ত কাজ ফিরিয়ে নিতে পারে। নিজে চেষ্টা করুন: একটি transaction শুরু (BEGIN), হেডফোনের মজুত ২টি কমানো, দেখা, তারপর ROLLBACK দিয়ে বাতিল করা:

BEGIN;
UPDATE products SET stock = stock - 2 WHERE product_id = 102;
SELECT product_id, name, stock FROM products WHERE product_id = 102;

ROLLBACK;   -- পুরো transaction বাতিল
SELECT product_id, name, stock FROM products WHERE product_id = 102;

নিরাপত্তা — কে কোন কলাম দেখবেন

SQLite একটি ফাইলেই চলে, তাই এতে user বা অনুমতির ব্যবস্থা নেই (অনুমতি নির্ভর করে ফাইলের ওপর)। PostgreSQL বা MySQL-এর মতো server DBMS-এ পরীক্ষা অফিসকে শুধু নির্দিষ্ট কলাম দেখানো যায়। নিচের কোডটি এই পাতায় চলবে না — শুধু দেখার জন্য:

CREATE ROLE exam_office LOGIN PASSWORD '...';
-- শুধু রোল, নাম আর নম্বর দেখতে পারবে; ফোন বা ফি নয়
GRANT SELECT (roll, name, mock1, mock2) ON students TO exam_office;
-- নম্বর বদলাতে পারবে, কিন্তু অন্য কিছু নয়
GRANT UPDATE (mock1, mock2) ON students TO exam_office;

এখন exam_office হিসেবে কেউ SELECT phone FROM students চালালে PostgreSQL “permission denied” বলবে। ফাইলের পুরো-অথবা-কিছুই-না অনুমতির তুলনায় এটি অনেক সূক্ষ্ম নিয়ন্ত্রণ। Role, privilege আর SQL injection প্রতিরোধ নিয়ে পর্ব ৫১.

৭ · DBMS-এর দাম — কখন সাধারণ ফাইলই যথেষ্ট

এতক্ষণ শুনে মনে হতে পারে, সব ডেটা ডেটাবেসে রাখাই বুদ্ধিমানের কাজ। তা নয়। প্রতিটি সুবিধার একটি দাম আছে, আর ভালো ইঞ্জিনিয়ার দাম জেনে বেছে নেন।

যেখানে সাধারণ ফাইলই ঠিক

• Log ফাইল: ওয়েব সার্ভারের access log শুধু শেষে নতুন লাইন যোগ করে (append), কেউ পুরোনো লাইন বদলায় না, একসাথে একজনই লেখে। এখানে transaction বা lock-এর দরকার নেই, আর text ফাইল সবচেয়ে দ্রুত।
• Configuration: অ্যাপের সেটিং — JSON, YAML বা .env ফাইল। মানুষ সহজে পড়ে, Git-এ পরিবর্তনের ইতিহাস থাকে।
• ছোট এক-ব্যবহারকারীর অ্যাপ: নিজের খরচের হিসাব, একটি স্ক্রিপ্টের ফল — CSV বা JSON যথেষ্ট।
• বড় মিডিয়া ফাইল: ছবি, ভিডিও, PDF সাধারণত ডিস্ক বা object storage-এ থাকে; ডেটাবেসে থাকে শুধু ফাইলের ঠিকানা আর বর্ণনা।
• এককালীন ডেটা আদান-প্রদান: এক প্রতিষ্ঠান থেকে আরেক প্রতিষ্ঠানে রিপোর্ট পাঠাতে CSV এখনো সবচেয়ে সর্বজনীন।

মাঝামাঝি একটি পথও আছে — SQLite. এটি সার্ভার ছাড়াই একটি সাধারণ ফাইলের ভেতরে পুরো relational database রাখে, transaction আর constraint-সহ। SQLite-এর নিজস্ব ওয়েবসাইট বলে, SQLite client/server ডেটাবেসের সাথে প্রতিযোগিতা করে না, প্রতিযোগিতা করে fopen()-এর (ফাইল খোলার সাধারণ ফাংশন) সাথে। ফোনের অ্যাপ, ব্রাউজার, ছোট ডেস্কটপ সফটওয়্যারের ভেতরে প্রায়ই SQLite থাকে — আর এই কোর্সের প্রতিটি লাইভ editor-ও SQLite-এ চলে। Python থেকে SQLite ব্যবহার দেখতে চাইলে Python কোর্সের ডেটাবেস পর্ব দেখুন।

৮ · ইতিহাস — IMS আর IDS থেকে Codd

ডেটাবেসের জন্ম কোনো একজনের মাথা থেকে এক দিনে হয়নি। ফাইল-সমস্যায় জর্জরিত বড় প্রতিষ্ঠানগুলো ১৯৬০-এর দশকে নিজেরাই সমাধান খুঁজতে শুরু করে। ধাপে ধাপে দেখুন:

৯ · আজকের “ফাইল সিস্টেম” — spreadsheet-এর ফাঁদ

আপনি হয়তো ভাবছেন, এসব তো ষাটের দশকের গল্প। কিন্তু আজকের যেকোনো অফিসে ঘুরে আসুন — বেতনের শিট, স্টকের শিট, ভর্তির শিট, প্রতিটি বিভাগের নিজের Excel বা Google Sheets. “final_v2_updated_REAL.xlsx” নামের ফাইল ইমেইলে ঘুরছে। এটি হুবহু আলোকিত কোচিংয়ের তিন ফাইলের গল্প। Spreadsheet চমৎকার টুল — হিসাব, চার্ট, দ্রুত বিশ্লেষণে অতুলনীয়। কিন্তু বহু মানুষের ভাগ করা, নিয়মে বাঁধা, দীর্ঘদিনের ডেটা রাখার জন্য এটি তৈরি হয়নি।

এগুলো কাল্পনিক ঝুঁকি নয়। ২০২০ সালের অক্টোবরে যুক্তরাজ্যে প্রায় ১৬ হাজার পজিটিভ কোভিড টেস্টের ফল সময়মতো contact tracing-এ পৌঁছায়নি, কারণ ফলগুলো পুরোনো .xls ফরম্যাটের একটি ফাইলে আনা হচ্ছিল, যার সারির সীমা পেরিয়ে যাওয়া অংশ নীরবে বাদ পড়ে। জিনবিজ্ঞানে Excel বহু বছর ধরে SEPT1, MARCH1-এর মতো জিনের নাম তারিখে বদলে দিত; শেষে ২০২০ সালে বিজ্ঞানীরা কয়েকটি জিনের নামই বদলে ফেলেন (যেমন SEPTIN1, MARCHF1). দুটি ঘটনাই একই শিক্ষা দেয়: ডেটা রাখার টুল যদি নিয়ম না জানে, ভুল নীরবে ঢোকে।

১০ · AI-এর যুগে — ফাইল না ডেটাবেস, আর AI-এর SQL যাচাই

আজ অনেকে AI-কে বলেন, “আমার দোকানের জন্য একটা হিসাবের প্রোগ্রাম বানিয়ে দাও।” AI প্রায়ই দ্রুততম পথটি বেছে নেয় — একটি CSV বা JSON ফাইলে সব রাখা। ছোট কাজে সেটি ঠিক; কিন্তু দুজন কর্মচারী একসাথে ব্যবহার শুরু করলেই এই পর্বের lost update আর inconsistency ফিরে আসে। AI নিজে থেকে প্রশ্ন করে না “কতজন একসাথে লিখবেন?” — প্রশ্নটি আপনাকেই তুলতে হবে।

আবার AI ডেটাবেস ব্যবহার করলেও তার SQL প্রায়ই চলে, কিন্তু ভুল: NULL ভুলভাবে সামলায় (যেমন উপরের শহরহীন Imran বাদ পড়ে যায়), JOIN-এ সারি দ্বিগুণ হয়ে যোগফল ফুলে ওঠে, এমন কলামের নাম বানায় যা আপনার টেবিলে নেই, constraint আর transaction ভুলে যায়, index-এর কথা ভাবে না।

AI-এর দেওয়া ডিজাইন বা SQL হাতে পেলে — যাচাইয়ের চেকলিস্ট

• একই তথ্য (ফোন, ঠিকানা, দাম) কি একাধিক টেবিলে কপি হয়েছে? হলে কেন — কারণ না থাকলে সরিয়ে দিন
• ব্যবসার প্রতিটি নিয়ম কি constraint হিসেবে ডেটাবেসে আছে, নাকি শুধু অ্যাপের কোডে?
• নমুনা ডেটায় চালিয়ে দেখেছি — NULL মানের সারি, কোনো অর্ডার নেই এমন গ্রাহক, বাতিল অর্ডার ঠিকভাবে এসেছে কি না
• একটি ফল হাতে হিসাব করে মিলিয়েছি, আর JOIN-এর আগে ও পরে সারির সংখ্যা তুলনা করেছি
• একাধিক ধাপের কাজ (টাকা জমা, মজুত কমানো) BEGIN … COMMIT-এর ভেতরে আছে
• প্রতিটি কলামের নাম আমার আসল schema-র সাথে মিলিয়েছি; বড় টেবিলে EXPLAIN দিয়ে plan দেখেছি (পর্ব ৪১)