লার্জ-ল্যাঙ্গুয়েজ-মডেল (LLM) এজেন্ট দ্বারা তৈরি Oracle SQL স্ক্রিপ্ট কাগজে-কলমে নিখুঁত মনে হলেও প্রোডাকশনে বড় ধরনের সমস্যা তৈরি করতে পারে। একটি ২.৩ মিলিয়ন লাইনের লিগ্যাসি কোডবেসে, একটি AI-চালিত এজেন্ট নিয়মিত এমন সব আইডেন্টিফায়ার ব্যবহার করছিল যা আসলে ছিল না – উদাহরণস্বরূপ, আসল STATUS_CD কলামের পরিবর্তে POLICY_STATUS ব্যবহার করা, অথবা CUSTOMER টেবিলের পরিবর্তে অস্তিত্বহীন CUSTOMERS টেবিলকে উল্লেখ করা।
টাইপো বা বানান ভুল ধরার জন্য স্ক্রিপ্টটি চালানো UPDATE বা DELETE স্টেটমেন্টের ক্ষেত্রে কোনো বিকল্প হতে পারে না। প্রোডাকশন-সদৃশ ডেটাসেটে এগুলো চালালে লক (locks) তৈরি হয়, সিকোয়েন্স নম্বর শেষ হয়ে যায় এবং এটি পর্যায়ক্রমিক পার্শ্বপ্রতিক্রিয়া (cascading side-effects) ঘটাতে পারে। ডেভেলপারদের ডেটা স্পর্শ না করেই নাম এবং সিনট্যাক্স যাচাই করার একটি উপায় প্রয়োজন। এর সমাধানটি আশ্চর্যজনকভাবে সহজ, আর তা হলো Oracle-এর EXPLAIN PLAN কমান্ড – যা একটি লিন্টিং (linting) ধাপ হিসেবে ব্যবহার করা যায়।
কীভাবে EXPLAIN PLAN একটি দ্রুত ভ্যালিডেটর হিসেবে কাজ করে
যখন Oracle একটি স্টেটমেন্ট পায়, এটি প্রথমে সেটি পার্স (parse) করে। পার্সিং করার সময় প্রতিটি রেফারেন্স করা টেবিল, কলাম এবং প্রিভিলেজ (privilege) বিদ্যমান কি না তা পরীক্ষা করা হয়, তারপর একটি এক্সিকিউশন প্ল্যান তৈরি করা হয় এবং সেই প্ল্যানটি একটি সিস্টেম টেবিলে লেখা হয়। এই কমান্ডটি কখনোই স্টেটমেন্টটি চালায় না: কোনো রো (row) পরিবর্তন হয় না, কোনো ট্রিগার (trigger) কাজ করে না এবং কোনো লক নেওয়া হয় না। যদি পার্সার কোনো অজানা অবজেক্টের সম্মুখীন হয়, তবে এটি কয়েক মিলিসেকেন্ডের মধ্যেই একটি এরর (error) প্রদান করে।
এই বৈশিষ্ট্যটি EXPLAIN PLAN-কে AI-জেনারেটেড SQL-এর জন্য একটি নিখুঁত প্রি-ফ্লাইট চেক (pre-flight check) হিসেবে গড়ে তোলে। কোনো টেবিল বা কলাম বাদ পড়লে তা তাৎক্ষণিকভাবে রিপোর্ট করা হয়, ফলে কোনো মানুষ স্ক্রিপ্টটি দেখার আগেই জেনারেশন লুপটি ভুলটি সংশোধন করতে পারে।
যে ওয়ার্কফ্লোটি আমি আমার CI পাইপলাইনে যুক্ত করেছি
- আগত স্ক্রিপ্টটিকে আলাদা আলাদা স্টেটমেন্টে বিভক্ত (Split) করুন।
- একটি ডেভেলপমেন্ট স্কিমার বিপরীতে
EXPLAIN PLAN FOR <statement>চালান (Run)। - Oracle থেকে প্রাপ্ত যেকোনো পার্সিং এরর (parsing errors) সংগ্রহ (Collect) করুন।
- পুনরায় চেষ্টা করার জন্য এররগুলো LLM-কে প্রদান (Feed) করুন।
বাস্তবে, মাত্র একটি রিট্রাই (retry) অধিকাংশ নামকরণের ভুল দূর করে দেয়। AI সঠিক স্কিমাটি শিখে নেয় এবং স্বয়ংক্রিয়ভাবে তার আউটপুট সমন্বয় করে। আমি এজেন্টটিকে রিড-অনলি (read-only) মোডেও লক করে রাখি: এটি SELECT এবং EXPLAIN PLAN কল করতে পারে, কিন্তু DDL, DML এবং COMMIT ব্লক করা থাকে। এই স্যান্ডবক্স (sandbox) নিশ্চিত করে যে AI যখন ডেটাবেসের গঠন পরীক্ষা করছে, তখন ডেটাবেসটি অপরিবর্তিত থাকে।
নামের যাচাইয়ের বাইরেও, জেনারেটেড প্ল্যানটি পারফরম্যান্সের স্পষ্ট সতর্কবার্তা (red flags) প্রকাশ করে। যদি কোনো স্টেটমেন্ট একটি বিশাল টেবিলের ওপর ফুল-টেবিল স্ক্যান (full-table scan) ট্রিগার করে, তবে কোনো রো স্পর্শ করার আগেই প্ল্যানটি তা দেখিয়ে দেয়, যা ডেভেলপারদের ইনডেক্স (index) ব্যবহারের পরামর্শ দিতে বা প্রেডিকেট (predicate) পুনরায় লেখার সুযোগ দেয়।
এই পদ্ধতির সীমাবদ্ধতা
- লজিক্যাল সঠিকতা যাচাই করা হয় না। একটি স্টেটমেন্ট যা সঠিক কলাম রেফারেন্স করে কিন্তু ভুল ফিল্টার প্রয়োগ করে, তাও লিন্ট (lint) পরীক্ষায় পাস করে যেতে পারে।
- PL/SQL ব্লক এর আওতার বাইরে। পার্সার শুধুমাত্র আলাদা SQL স্টেটমেন্টগুলো হ্যান্ডেল করে; প্রসিডিউরাল কোডের জন্য আলাদা ভ্যালিডেশন পথের প্রয়োজন।
- ডেটা-লেভেল ভ্যালিডেশন অনুপস্থিত। লিন্ট আপনাকে বলতে পারবে না যে একটি লিটারেল ভ্যালু (literal value) কোনো কলামের ডোমেনের সাথে সামঞ্জস্যপূর্ণ কি না বা একটি ফরেন-কী (foreign-key) রেফারেন্স আসলে বিদ্যমান কি না।
- শুধুমাত্র ডেভ (Dev) স্কিমা। যেসব এরর শুধুমাত্র প্রোডাকশনে দেখা দেয় – উদাহরণস্বরূপ, একটি টেবিল যা ডেভ স্কিমাতে আছে কিন্তু প্রোডাকশনে নাম পরিবর্তন করা হয়েছে – সেগুলো পরে না হওয়া পর্যন্ত অদৃশ্য থেকে যায়।
এই ঘাটতিগুলো পদ্ধতির উপযোগিতা কমিয়ে দেয় না; এগুলো কেবল এর পরিধি নির্ধারণ করে। বেশিরভাগ LLM-জেনারেটেড DML স্ক্রিপ্টের ক্ষেত্রে সবচেয়ে সাধারণ ব্যর্থতা হলো টাইপো বা ভুল অবজেক্টের নাম, আর EXPLAIN PLAN ঠিক সেটিই ধরে ফেলে।
অন্যান্য ডেটাবেস ইঞ্জিনে পোর্টেবিলিটি
একই নীতি Oracle-এর বাইরেও প্রযোজ্য। PostgreSQL-এর PREPARE স্টেটমেন্ট বা EXPLAIN কোনো কুয়েরি এক্সিকিউশন ছাড়াই পার্স করতে পারে। SQL Server SET PARSEONLY ON সুবিধা দেয়, যা ইঞ্জিনকে প্রকৃত প্রসেসিং বাদ দিয়ে সিনট্যাক্স এবং অবজেক্টের নাম যাচাই করতে বাধ্য করে। যে কোনো RDBMS যা পার্সিং এবং এক্সিকিউশনকে আলাদা করে, তা একটি হালকা ওজনের লিন্টিং গেট (linting gate) হিসেবে কাজ করতে পারে।
মূল কথা (Takeaway)
প্রতিটি AI-জেনারেটেড SQL স্টেটমেন্টের ওপর EXPLAIN PLAN (বা এর সমতুল্য) চালানো একটি ডেটাবেস পার্সারকে একটি সাশ্রয়ী এবং ঝুঁকিমুক্ত লিন্টিং গেটে পরিণত করে। এটি কোনো ডেটা পরিবর্তন করার আগেই সবচেয়ে সাধারণ নামকরণের এবং সিনট্যাক্সের ভুলগুলো ধরে ফেলে, যা লিগ্যাসি সিস্টেমগুলোকে স্থিতিশীল রাখে এবং একই সাথে ডেভেলপারদের LLM-সহায়তা সম্পন্ন কোডিংয়ের মাধ্যমে উৎপাদনশীলতা বৃদ্ধির সুযোগ দেয়।