কিভাবে LLM‑গুলো প্রোডাক্ট চাহিদা থেকে ডেটাবেস বেছে নেয়—এবং কোথায় ব্যর্থ হয়

কেন মানুষ LLM-কে ডেটাবেস বেছে নিতে বলে

টিমরা LLM-কে ডেটাবেস সুপারিশ করতে বলে ঠিক যেভাবে ইমেইল খসড়া বা স্পেসিফিকেশন সারসংক্ষেপ করতে বলে: শুরু করা অপেক্ষাকৃত দ্রুত। যখন PostgreSQL, DynamoDB, MongoDB, Elasticsearch, Redis, ClickHouse ইত্যাদির মধ্যে পছন্দ করতে হয়, একটি LLM দ্রুত একটি শর্টলিস্ট তৈরি করে, ট্রেড-অফগুলি বর্ণনা করে, এবং টিম আলোচনা শুরু করার জন্য "ভাল-পর্যাপ্ত" শুরু পয়েন্ট দেয়।

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

“প্রোডাক্ট চাহিদা থেকে অনুমান” আসলে কি বোঝায়

সরলভাবে আপনি প্রোডাক্টটি বর্ণনা করেন ("একটি মার্কেটপ্লেস যেখানে লিস্টিং এবং চ্যাট আছে"), ডেটা ("ইউজার, অর্ডার, মেসেজ") এবং সীমাবদ্ধতা ("1M ব্যবহারকারী পর্যন্ত স্কেল করতে হবে, দ্রুত সার্চ দরকার, কম অপস খরচ")। LLM তারপর সেই চাহিদাগুলোকে সাধারণ আর্কিটেকচারাল প্যাটার্নগুলোর সাথে ম্যাপ করে:

• রিলেশনাল ডেটা → SQL
• নমনীয় ডকুমেন্ট → ডকুমেন্ট স্টোর
• অ্যানালিটিকস → কলামর-ওরিয়েন্টেড ওয়্যারহাউস
• ক্যাশিং → কি-ভ্যালু স্টোর
• ফুল-টেক্সট সার্চ → সার্চ ইঞ্জিন

এই ম্যাপিং প্রাথমিক পর্যায়ে সত্যিই সহায়ক হতে পারে, বিশেষত যখন বিকল্পটি পুরোপুরি খালি পাতা।

পরামর্শ বনাম চূড়ান্ত আর্কিটেকচার সিদ্ধান্ত

একটি LLM সুপারিশকে একটি হাইপোথেসিস হিসেবে নেয়া ভাল, বিচার হিসাবে নয়। এটি সাহায্য করতে পারে:

• মূল প্রশ্নগুলোকে নামকরণ করতে
• স্পষ্ট মিসম্যাচগুলো আগে সনাক্ত করতে
• একটি ডিসিশন মেমো খসড়া করতে যা আপনি টিমের সাথে পরিশোধন করবেন

কিন্তু এটি আপনার বাস্তব ট্র্যাফিক ধরন, ডেটা বৃদ্ধির হারের, টিম স্কিল, ভেন্ডর সীমাবদ্ধতা, বা অপারেশনাল সহিষ্ণুতা ছাড়া সঠিকভাবে জানতে পারে না—এবং এমনকি সেগুলো দিলেও এটি উৎপাদন পরীক্ষা চালাবে না।

কী ভুল হতে পারে (এবং ঝুঁকি কমানোর উপায়)

LLM-গুলি প্রেডিক্টেবলভাবে ব্যর্থ হয়: জনপ্রিয় রুল অফ থাম্বগুলোর ওপর নির্ভর করে, অনুপস্থিত বিবরণ আন্দাজ করে, ট্রানজ্যাকশন ও কনসিস্টেন্সি চাহিদা উপেক্ষা করে, বেঞ্চমার্ক ছাড়া পারফরম্যান্স ধরে নেয়, এবং খরচ ও অপারেশনাল বোঝা কম মূল্যায়ন করে।

নিচে এই ব্যর্থতা মোডগুলো বিশ্লেষণ করা হয়েছে এবং শেষেই একটি ব্যবহারিক চেকলিস্ট আছে যাতে আপনি যেকোনো LLM ডেটাবেস পরামর্শ বিবেচনা করার আগে যাচাই করতে পারেন।

LLM কিভাবে রিকোয়্যারমেন্টকে ডেটাবেস পছন্দে রূপান্তর করে

যখন আপনি একটি LLM-কে “ডেটাবেস সুপারিশ করুন” বলেন, এটি ইঞ্জিনিয়ারের মতো ডেটাবেসগুলো মূল্যায়ন করে না। এটি আপনার প্রোম্পটকে অনুমিত রিকোয়্যারমেন্টে রূপান্তর করে, সেগুলোকে তার দেখা প্যাটার্নগুলোর সাথে মিলায়, এবং তারপর এমন উত্তর দেয় যা সিদ্ধান্তের মতো পড়ে।

এটি কীকে ইনপুট হিসেবে গ্রহণ করে

ইনপুট কেবল আপনার সরাসরি দেওয়া বিবরণ নয় (ট্রাফিক, ডেটা সাইজ, কনসিস্টেন্সি চাহিদা)। মডেলটি আরও ব্যবহার করে:

• আপনার প্রোম্পটের বাক্যগঠন ও স্ট্রাকচার (আপনি কী জোর দিয়েছেন, কী বাদ দিয়েছেন)
• আপনার প্রোডাক্ট বর্ণনা ("চ্যাট", "অ্যানালিটিকস", "পেমেন্ট", "IoT" ইত্যাদিকে সাধারণ আর্কিটেকচারের সাথে ম্যাপ করে)
• উল্লিখিত সীমাবদ্ধতা (ক্লাউড প্রোভাইডার, বাজেট, টিম স্কিল, ডেডলাইন)
• ট্রেনিং ডেটা থেকে শেখা "পূর্বের প্যাটার্ন" (সাধারণ স্ট্যাক, জনপ্রিয় ব্লগ পরামর্শ, ঘন ঘন জোড়া করা)

অনেক প্রোম্পট অসম্পূর্ণ হওয়ায়, মডেল প্রায়ই খাঁড়ি অংশগুলো পূরণ করে—কখনও কখনও সঠিকভাবে, কখনও না।

এটি কী আউটপুট তৈরি করে

বেশিরভাগ উত্তর তিনটি স্তরে আঘাত করে:

1. একটি ক্যাটাগরি পছন্দ (SQL বনাম NoSQL; রিলেশনাল বনাম ডকুমেন্ট বনাম কী-ভ্যালু)
2. নির্দিষ্ট ইঞ্জিন (PostgreSQL, MySQL, DynamoDB, MongoDB, BigQuery, Redis)
3. “শ্রেষ্ঠ অনুশীলন”-এর বান্ডেল (ইন্ডেক্স, ক্যাশিং, রিড রিপ্লিকা, শার্ডিং, ইভেন্ট সোর্সিং)

ফলাফলটি পরিষ্কার সুপারিশের মত অনুভূত হতে পারে, কিন্তু প্রায়ই এটি ঐতিহ্যবাহী অপশনগুলোর একটি সংগঠিত সারসংক্ষেপ।

কেন এটি আত্মবিশ্বাসী শোনায় অথচ নিশ্চিত নয়

LLMগুলো উদাহরণ থেকে সাধারণিকরণ করে; তারা আপনার ওয়ার্কলোড চালায় না, আপনার স্কিমা পরীক্ষা করে না, বা কুয়েরি বেঞ্চমার্ক করে না। যদি ট্রেনিং ডেটা “উচ্চ স্কেল” কে “NoSQL” এর সাথে দৃঢ়ভাবে যুক্ত করে, আপনি সেই উত্তর পেয়ে যেতে পারেন যদিও ভাল-টিউন করা একটি SQL সিস্টেম উপযুক্ত হত।

আত্মবিশ্বাসী ভাষা একটি স্টাইল—মাপ নয়। যদি মডেল স্পষ্টভাবে অনুমান না বলে ("আমি ধরছি বেশি অংশে অ্যাপেন্ড-অনলি রাইট আছে এবং eventual consistency গ্রহণযোগ্য"), তখনcertainty লুকানো থাকতে পারে: অনুপস্থিত ইনপুট এবং অটেস্ট করা পারফরম্যান্স দাবি।

“প্রোডাক্ট চাহিদা” আসলে কী অন্তর্ভুক্ত করে

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

কার্যকরী চাহিদা (আপনি কী নির্মাণ করবেন)

প্রোডাক্টের আকার থেকে শুরু করুন: মূল এন্টিটিগুলো, কীভাবে তারা সম্পর্কিত, এবং কোন কুয়েরিগুলো বাস্তব ওয়ার্কফ্লো চালায়।

আপনি কি বহু-অ্যাট্রিবিউট জুড়ে অ্যাড-হক ফিল্টারিং ও রিপোর্টিং দরকার? আপনি কি রিলেশনশিপ জোড়া ব্যবহার করবেন? আপনি কি সাধারণত একটি রেকর্ড আইডি দ্বারা পড়বেন, না টাইম-রেঞ্জ স্ক্যান করবেন? এসব বিস্তারিত নির্ধারণ করে SQL টেবিল, ডকুমেন্ট মডেল, ওয়াইড-কলাম প্যাটার্ন, বা সার্চ ইনডেক্সদের মধ্যে কোনটি সেরা।

ননফাংশনাল চাহিদা (কীভাবে এটি আচরণ করবে)

ডেটাবেস বাছাই ফিচারগুলোর তুলনায়_constraints_ দ্বারা অনেকটাই নির্ধারিত:

• ল্যাটেন্সি লক্ষ্য (p95/p99) কী কী উজেলার জন্য প্রযোজ্য
• অভিগম্যতা ও পুনরুদ্ধার প্রয়োজন (কতটা ডাউনটাইম গ্রহণযোগ্য?)
• রিড/রাইট মিক্স ও পিক ট্রাফিক প্যাটার্ন
• ৬–২৪ মাসে ডেটা ভলিউম ও ট্রাফিক বৃদ্ধি হার

যারা কয়েক সেকেন্ড বিলম্ব সহ্য করতে পারে তাদের জন্য সিস্টেম সম্পূর্ণ আলাদা, যাদের পেমেন্ট কনফার্ম করতে <200ms দরকার তাদের জন্য।

অপারেশনাল চাহিদা (আপনি কী চালাতে পারবেন)

এমনকি একটি “পারফেক্ট” ডেটা মডেল ব্যর্থ হবে যদি অপারেশন আপনার সাথে ফিট না করে:

• ব্যাকআপ ও রিস্টোর টেস্টিং
• মাইগ্রেশন ও স্কিমা ইভলিউশন
• অন-কল বোরডেন ও স্টাফিং (DBA অভিজ্ঞতা বনাম জেনারালিস্ট)
• ভেন্ডর সীমা: ম্যানেজড সার্ভিস কোটা, এলাকা সাপোর্ট, মেইনটেন্যান্স উইন্ডো

নিয়ন্ত্রক চাহিদা (আপনি কী প্রমাণ করতে হবে)

কমপ্লায়েন্স দ্রুত পছন্দগুলি সংকীর্ণ করে:

• ডেটা রিটেনশন ও ডিলিশন গ্যারান্টি
• অডিট ট্রেইল (কে কী বদলে ফেলেছে, কবে)
• এক্সেস কন্ট্রোল, এনক্রিপশন, আলাদা দায়িত্ব

LLM-গুলি এই চাহিদাগুলোকে অস্পষ্ট প্রোম্পট থেকে অনুমান করে—এখানে স্পষ্ট হওয়াই হেল্পফুল সুপারিশ ও আত্মবিশ্বাসী ভুলের মধ্যে পার্থক্য।

কোথায় LLM যুক্তি বাস্তবতা থেকে বিচ্যুত হতে পারে

LLM প্রায়ই কয়েকটি উল্লিখিত চাহিদাকে (“রিয়েল-টাইম”, “স্কেল”, “নমনীয় স্কিমা”) একটি পরিচিত ক্যাটাগরি লেবেলে ম্যাপ করে (“NoSQL ব্যবহার করুন”, “Postgres ব্যবহার করুন”)। এটি ব্রেনস্টর্মিংয়ের জন্য উপকারী হতে পারে, কিন্তু মডেল যখন ডেটাবেস ফিচার কে প্রোডাক্ট রিকোয়্যারমেন্ট হিসেবে ধরে নেয় তখন যুক্তি বিচ্যুত হয়।

ফিচার ≠ প্রোডাক্ট চাহিদা

একটি ফিচার তালিকা (ট্রানজ্যাকশন, JSON সাপোর্ট, ফুল-টেক্সট সার্চ, শার্ডিং) কিছুকে কংক্রিট মনে করায়, তবু প্রোডাক্ট চাহিদা সাধারণত আউটকাম বর্ণনা করে: গ্রহণযোগ্য লেটেন্সি, সঠিকতার নিয়ম, অডিটযোগ্যতা, টিম স্কিল, মাইগ্রেশন সীমাবদ্ধতা, বাজেট।

একটি LLM ফিচারগুলো যাচাই করে এবং তারপরও মিস করতে পারে যে প্রোডাক্টকে কী ধরনের সাপোর্ট ও হোস্টিং দরকার যা আপনার কোম্পানি ব্যবহার করতে পারে।

চেকলিস্টগুলো আপনার ডেটা ও কুয়েরির আকৃতি মিস করে

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

দুইটি সিস্টেমই "ইউজার ইভেন্ট" স্টোর করতে পারে, কিন্তু তারা একেবারেই আলাদা আচরণ করবে যদি আপনার দরকার

• বহু মাত্রিক অ্যাড-হক অ্যানালিটিকস
• প্রতি-ইউজার টাইমলাইন কঠোর অর্ডারিংসহ
• ক্রস-এন্টিটি কনস্ট্রেইন্ট (যেমন, ইনভেন্টরি কখনো শূন্যের নিচে যাবে না)

পারফরম্যান্স একটি ইমপ্লিমেন্টেশন বিবরণ, প্রতিশ্রুতি নয়

LLM বলতে পারে “ডেটাবেস X দ্রুত”, কিন্তু পারফরম্যান্স নির্ভর করে স্কিমা চয়েস, ইনডেক্স, পার্টিশনিং, কুয়েরি প্যাটার্ন, এবং কনকারেন্সিতে। ক্ষুদ্র পরিবর্তন—কমপোজিট ইনডেক্স যোগ করা বা অনবাউন্ডেড স্ক্যান এড়ানো—ফল উল্টে দিতে পারে। প্রতিনিধি ডেটা এবং কুয়েরি ছাড়া “দ্রুত” কেবল অনুমান।

অপারেশনাল ফিট কাঁচামাল ক্ষমতার চাইতে বেশি গুরুত্ব পেতে পারে

যদিও দুটি ডেটাবেস প্রযুক্তিগতভাবে চাহিদা পূরণ করতে পারে, ভাল পছন্দটি হতে পারে যে যা আপনার টিম নির্ভরযোগ্যভাবে চালাতে পারে: ব্যাকআপ এবং রিস্টোর সময়, মনিটরিং, অন-কল লোড, ভেন্ডর লক-ইন, খরচ পূর্বানুমান, এবং কমপ্লায়েন্স।

LLM-গুলি এগুলোকে সাধারণত কম আংশিকভাবে গুরুত্ব দেয় যদি না আপনি স্পষ্টভাবে এগুলো প্রদান করেন।

ব্যর্থতার মোড ১: জনপ্রিয় রুল অফ থাম্ব থেকে অতিরঞ্জন করা

LLM প্রায়ই সাধারণভাবে ব্যবহৃত “রুল” গুলো ধরেই উত্তর দেয়, যেমন “NoSQL ভাল স্কেল করে” বা “Postgres সবই করতে পারে।” এই শর্টকাটগুলো আত্মবিশ্বাসী শোনায়, কিন্তু তারা প্রোডাক্টের জটিল বাস্তবতা সমতল করে দেয়: আপনি কী স্টোর করেন, কীভাবে কুয়েরি হয়, এবং কিভাবে সমস্যা দেখা দিলে ব্যর্থতা কেমন দেখায়।

ক্লাসিক শর্টকাট: “স্কেলের জন্য NoSQL ব্যবহার করুন”

একটি সাধারণ প্যাটার্ন হলো ধরেই নেওয়া যে আপনি বৃদ্ধি, উচ্চ ট্রাফিক, বা “বড় ডেটা” উল্লেখ করলে NoSQL নিরাপদ পছন্দ। সমস্যা হলো “স্কেল” প্রায়শই প্রথম অদূরস্থ সমস্যা নয়। অনেক অ্যাপ সীমায় পৌঁছায় কারণ:

• ইনডেক্স অনুপস্থিত বা অকার্যকর কুয়েরি
• অপরিমিত ডেটা রিটেনশন
• খারাপ ক্যাশিং কৌশল
• অপর্যাপ্ত রিসোর্স প্রভিডিং

এই ক্ষেত্রে, ডেটাবেস বদলানো মূল কারণ সারায় না—শুধু টুল বদলে যায়।

যা উপেক্ষা করা হয়: জয়েন, ট্রানজ্যাকশন, এবং কঠোর সঠিকতা

রুল অফ থাম্বগুলো এমন প্রয়োজনগুলোকে মসৃণ করে দেয় যা ডেটাবেস ফিটকে ভারীভাবে প্রভাবিত করে। একটি LLM ডকুমেন্ট স্টোর সুপারিশ করতে পারে যখন আপনি প্রকৃতপক্ষে প্রয়োজন:

• বহু-ধাপ আপডেট যা একসাথে সফল বা ব্যর্থ হতে হবে (ট্রানজ্যাকশন)
• ব্যালান্স, ইনভেন্টরি, বা বুকিংয়ের জন্য কঠোর সঠিকতা (স্ট্রং কনসিস্টেন্সি)
• এন-টাইপের রিপোর্টিং কুয়েরি যা এন্টিটিগুলো একত্র করে (জটিল জয়েন)

এই চাহিদাগুলো নিজে থেকেই NoSQL বাতিল করে না, কিন্তু বার বাড়ায়: আপনাকে সতর্ক স্কিমা ডিজাইন, অতিরিক্ত অ্যাপ লজিক, বা LLM ইঙ্গিত করা ট্রেড-অফগুলোর থেকে ভিন্ন সমাধান নিতে হতে পারে।

কেন এই ব্যর্থতা ব্যয়বহুল

যখন সুপারিশ একটি শ্লোগানের উপর ভিত্তি করে নির্মিত হয় না আপনার প্রকৃত অ্যাক্সেস প্যাটার্নের উপর, ঝুঁকি কেবল একটি অপ্রয়োজনীয় পছন্দ নয়—এটি পরে মহঙ্গা রি-প্ল্যাটফর্মিং। ডেটা মাইগ্রেট করা, কুয়েরি রাইট করা, এবং টিমকে পুনরায় প্রশিক্ষণ দেওয়া সাধারণত তখনই ঘটে যখন আপনার কাছে ডাউনটাইম সবচেয়ে কম চল।

“রুল” গুলোকে প্রশ্নের জন্য প্রম্পট হিসেবে ব্যবহার করুন, উত্তর হিসাবে নয়। জিজ্ঞাসা করুন আপনি কি স্কেল করছেন (রিড, রাইট, অ্যানালিটিকস), কী অবশ্যই সঠিক থাকতে হবে, এবং কোন কুয়েরিগুলো এড়ানো যাবে না।

ব্যর্থতার মোড ২: অনুপস্থিত বা অস্পষ্ট ইনপুট

LLM সংক্ষিপ্ত বিবরণকে একটি আত্মবিশ্বাসী ডেটাবেস পছন্দে রূপান্তর করতে ভাল—কিন্তু এটি অনুপস্থিত সীমাবদ্ধতাগুলো উদ্ভাবন করতে পারে না যেগুলো আসলে সিদ্ধান্ত নির্ধারণ করে। ইনপুটগুলো অস্পষ্ট হলে সুপারিশটি একটি অনুমান হয়ে যায় যাকে উত্তর বলা হয়েছে।

“রিয়েল-টাইম” এবং “উচ্চ ট্রাফিক” ফাঁদ

“রিয়েল-টাইম”, “উচ্চ ট্রাফিক”, “স্কেলেবল”, বা “এন্টারপ্রাইজ-গ্রেড” এর মতো শব্দগুলো স্পষ্টভাবে কোনো নির্দিষ্ট ডেটাবেস ম্যাপ করে না। “রিয়েল-টাইম” হতে পারে একটি ড্যাশবোর্ডের জন্য “৫ সেকেন্ডের মধ্যে আপডেট”—বা ট্রেডিং অ্যালার্টের জন্য “৫০ms-র কম এন্ড-টু-এন্ড”। “উচ্চ ট্রাফিক” হতে পারে ২০০ RPS বা ২০০,০০০।

কঠোর সংখ্যার ছাড়া, একটি LLM জনপ্রিয় হিউরিস্টিক (যেমন, “স্কেলের জন্য NoSQL”, “সবকিছুর জন্য Postgres”) ফিরিয়ে দিতে পারে যদিও প্রকৃত চাহিদা অন্য কোথাও নির্দেশ করে।

উত্তর বদলে দেওয়ার মতো সংখ্যা যা ফলাফল পরিবর্তন করে

যদি আপনি এগুলো না দেন, মডেল গোপনীয়ভাবে অনুমান করবে:

• রিড/রাইট QPS (পিক বনাম এভারেজ)
• p95/p99 লেটেন্সি টার্গেট (রিড/রাইটের জন্য পৃথকভাবে)
• ডেটাসেট সাইজ এখন, বৃদ্ধি হার, রিটেনশন পলিসি
• অবজেক্ট সাইজ (ওয়াইড রো? বড় ব্লব?) এবং ইনডেক্স কার্ডিনালিটি

আপনি ভুলে যাওয়া লুকানো কুয়েরি প্যাটার্ন

সবচেয়ে ক্ষতিকর অনুপস্থিততাগুলো প্রায়শই কুয়েরি-আকৃতির:

• রিপোর্টিং ও অ্যানালিটিকস (গ্রুপ-বাই, টাইম বাকেট)
• বহু ফিল্ডে ফিল্টার/সোর্টিং
• সাপোর্ট ও ডিবাগের জন্য অ্যাড-হক কুয়েরি
• ব্যাকফিল, রি-প্রসেসিং, এবং “ইউজার X-এর সবকিছু দেখাও” লুকআপ

কি-ভ্যালু এক্সেসে দক্ষ ডেটাবেস প্রোডাক্ট ঠিক একেবারে বিপরীত হতে পারে যখন হঠাৎ প্রোডাক্টে নমনীয় ফিল্টারিং ও বিশ্বাসযোগ্য রিপোর্টিং দরকার হয়।

ব্যবহারিক টিপ: সুপারিশ দেওয়ার আগে স্পষ্টকরণ বাধ্যতামূলক করুন

“ডেটাবেস সিলেকশন” কে দুই-ধাপ ইন্টার‍্যাকশন হিসেবে বিবেচনা করুন: প্রথমে কনস্ট্রেইন্টগুলো সংগ্রহ করুন, তারপর সুপারিশ করুন। একটি ভাল প্রোম্পট (বা অভ্যন্তরীণ চেকলিস্ট) নাম্বার ও উদাহরণ কুয়েরি চাওয়া পর্যন্ত ডাটাবেস নাম বলবে না।

ব্যর্থতার মোড ৩: ডেটা মডেল মিল না থাকা

একটি সাধারণ LLM ত্রুটি হচ্ছে একটি ডেটাবেস "ক্যাটাগরি" (SQL, ডকুমেন্ট, গ্রাফ, ওয়াইড-কোলাম) সুপারিশ করা কিন্তু যাচাই না করা যে প্রোডাক্টের ডেটা বাস্তবেই সেই মডেলে ফিট করে কি না। ফলাফল: এমন একটি স্টোর বেছে নেওয়া যা ওয়ার্কলোডের জন্য সঠিক শোনায়, কিন্তু আপনি যে তথ্যটি উপস্থাপন করতে চান তার কাঠামোর সাথে লড়াই করে।

মিসম্যাচ সাধারণত সম্পর্কগুলোর গভিরতা থেকে শুরু হয়

LLM গুলো প্রায়ই সম্পর্কের গভীরতা ও কার্ডিনালিটি উপেক্ষা করে: এক-থেকে-অনেক বনাম বহু-থেকে-অনেক, নেস্টেড ওনারশিপ, শেয়ারড এন্টিটিগুলি, এবং ইউজাররা কীভাবে সেগুলোর মধ্যে ট্রাভার্স করে তা।

একটি ডকুমেন্ট ডেটাবেস "ইউজার প্রোফাইল" এর জন্য ন্যাচারাল মনে হতে পারে, কিন্তু যদি আপনার প্রোডাক্ট ক্রমাগত ক্রস-এন্টিটি কুয়েরি করে—“যে কোনো সদস্যের রোল শেষ ৭ দিনে বদলেছে এমন সব প্রজেক্ট” বা “কমপ্লায়েন্স স্ট্যাটাস দ্বারা ফিল্টার করে টিমগুলোর সব জায়গায় শীর্ষ ২০ ট্যাগ”—তাহলে আপনি কেবল একটি ডকুমেন্ট ফেচ করছেন না; আপনি জয়েন করছেন।

যদি সেই জয়েনগুলি ঘনঘন হয়, আপনাকে হয়:

• অ্যাপ্লিকেশন লজিকে জয়েন সিমুলেট করতে হবে (অতিরিক্ত রাউন্ড ট্রিপ এবং জটিলতা), অথবা
• ব্যাপকভাবে ডেনর্মালাইজ করতে হবে (ডকুমেন্টে ডুপ্লিকেট ডেটা)

ডেনর্মালাইজেশনের লুকানো খরচ

ডুপ্লিকেশন বিনামূল্যের নয়। এটি লিখার অ্যাম্প্লিফিকেশন বাড়ায়, আপডেট বজায় রাখা কঠিন করে, অডিট জটিল করে, এবং সূক্ষ্ম বাগ তৈরি করতে পারে ("কোন কপি হল সোর্স অব ট্রুথ?")। LLM গুলো কেতাবিভাবে ডেনর্মালাইজেশনকে এককালীন মডেলিং সিদ্ধান্ত হিসেবে সুপারিশ করে, অথচ এটি একটি চলমান অপারেশনাল বোঝা।

স্যানিটি চেক: প্রার্থী স্কিমা + মূল কুয়েরি

একটি LLM সুপারিশ গ্রহণের আগে একটি দ্রুত বাস্তবতা পরীক্ষা জোর করুন:

1. একটি প্রার্থী স্কিমা স্কেচ করুন (টেবিল/কনকালেকশন/নোড) প্রাইমারি কিসহ এবং কয়েকটি গুরুত্বপূর্ণ সম্পর্ক।
2. ৫–১০ টি “কী কুয়েরি” লিখুন যা প্রোডাক্টকে সমর্থন করতে হবে (ফিল্টার, সোর্ট, অগ্রিগেশন, ক্রস-এন্টিটি লুকআপ)।
3. জিজ্ঞাসা করুন: এই ডেটাবেস কি এই কুয়েরিগুলো স্বাভাবিকভাবে ও কার্যকরভাবে প্রকাশ করে, কোনো হিরোইক ডেনর্মালাইজেশন বা বহু-ধাপ অ্যাপ জয়েন ছাড়াই?

যদি মডেল আর কুয়েরিগুলো মেলে না, সুপারিশ হলো শূন্য—এমনকি যদি এটি আত্মবিশ্বাসী শোনাক।

ব্যর্থতার মোড ৪: ট্রানজ্যাকশন ও কনসিস্টেন্সি ব্লাইন্ডস্পট

LLM প্রায়ই “কনসিস্টেন্সি” কে একটি পছন্দ হিসেবে মানে, একটি প্রোডাক্ট কনস্ট্রেইন্ট হিসেবে নয়। ফলে এমন সুপারিশ আসতে পারে যা কাগজে যুক্তিযুক্ত দেখায় ("স্কেলেবল NoSQL স্টোর ব্যবহার কর"), কিন্তু বাস্তবে ভেঙে পড়ে যখন ব্যবহারকারীর অ্যাকশনগুলো অ্যাটোমিক, বহু-ধাপ আপডেট দাবি করে।

অ্যাটোমিসিটি গ্যাপ: বহু-ধাপ আপডেট যা একসাথে সফল হতে হবে

অনেক প্রোডাক্ট ফ্লো কেবল একটি লিখে শেষ হয় না—এগুলো কয়েকটি লিখে যা একসাথে ঘটতে হবে অথবা একদমই না ঘটতে হবে।

পেমেন্ট ক্লাসিক উদাহরণ: চার্জ তৈরি করা, ইনভয়েস পেইড চিহ্নিত করা, অ্যাকাউন্ট ব্যালান্স হ্রাস করা, এবং একটি অডিট রেকর্ড অ্যাপেন্ড করা। যদি প্রথমটি সফল হয় এবং পরেরগুলো ব্যর্থ হয়, আপনি ব্যবহারকারী ও ফাইন্যান্সের জন্য অমিল তৈরি করেছেন।

ইনভেন্টরি সামঞ্জস্য: রিজার্ভ স্টক, অর্ডার তৈরি, এবং অ্যাভেইলেবিলিটি আপডেট—ট্রানজ্যাকশন ছাড়া আপনি স্পাইক সময় অতিবিক্রি হতে পারেন বা আংশিক ব্যর্থতা ঘটতে পারে।

ইভেন্টুয়াল কনসিস্টেন্সি মানে “ইউজাররা পরে আপডেট দেখবে” নয়

LLM কখনও কখনও ইভেন্টুয়াল কনসিস্টেন্সিকে "UI পরে রিফ্রেশ করবে" হিসেবে মেনে নেয়। কিন্তু প্রশ্নটা হলো ব্যবসায়িক অ্যাকশন কি বিচ্যুতি সহ্য করতে পারে কি না।

বুকিং কনফ্লিক্ট দেখায় কেন এটা জরুরি: দুইজন ব্যবহারকারী একই সময় স্লট বুক করার চেষ্টা করলে। যদি সিস্টেম দুজনকেই গ্রহণ করে এবং পরে “সামঞ্জস্য করে,” আপনি UX উন্নত করছেন না—আপনি কাস্টমার সাপোর্ট ও ফেরত সমস্যার মোড় নিচ্ছেন।

অপারেশনাল সেমান্টিক্সের অভাব: আইডেমপটেন্সি, রিট্রাই, এবং এক্সাক্টলি-ওয়ান

একটি ডেটাবেস যা ট্রানজ্যাকশন সাপোর্ট করে, তার সত্ত্বেও চারপাশের ওয়ার্কফ্লো স্পষ্ট সেমান্টিক্স চাই:

• আইডেমপটেন্সি কি যাতে “পে” দুবার চাপলে দুইবার চার্জ না হয়।
• রিট্রাই গুলো আংশিক ব্যর্থতা ও টাইমআউটের অধীনে সেফ কি না।
• এক্সাক্টলি-ওয়ান ইফেক্ট (বা ইচ্ছাকৃতভাবে "অ্যাট-লিস্ট-ওয়ান + ডিডিউপ") ইভেন্ট, ওয়েবহুক, এবং ব্যাকগ্রাউন্ড জবগুলোর জন্য।

যখন একটি LLM এগুলো উপেক্ষা করে, তখন এটি এমন আর্কিটেকচার সুপারিশ করতে পারে যা সাধারণ প্রোডাক্ট সঠিকতা অর্জন করতে বিশেষজ্ঞ-স্তরের ডিস্ট্রিবিউটেড সিস্টেম কাজ দাবি করে।

ব্যর্থতার মোড ৫: পরীক্ষা ছাড়া পারফরম্যান্স অনুমান

LLM প্রায়ই একটি “দ্রুত” ডেটাবেস সুপারিশ করে যেন গতি ইঞ্জিনের নিজস্ব বৈশিষ্ট্য। বাস্তবে, পারফরম্যান্স হল আপনার ওয়ার্কলোড, স্কিমা, কুয়েরি আকৃতি, ইনডেক্স, হার্ডওয়্যার, এবং অপারেশনাল সেটিংসের মধ্যে ইন্টারঅ্যাকশন।

ওয়ার্কলোড কনটেক্সট ছাড়া “দ্রুত”

আপনি কি দ্রুততা চান—p99 লেটেন্সি এক-রো রিডের জন্য, ব্যাচ অ্যানালিটিকস, ইনজেশন থ্রুপুট, না টাইম-টু-ফার্স্ট-বাইট—প্রশ্নটি নির্দিষ্ট না হলে LLM জনপ্রিয় পছন্দে ডিফল্ট হতে পারে।

দুইটি প্রোডাক্টই “নিম্ন লেটেন্সি” বলতে পারে, তবু তাদের অ্যাক্সেস প্যাটার্ন মোটেও একই নাও হতে পারে: একটি কি-ভ্যালু লুকআপ; অন্যটি সার্চ+ফিল্টার+সোর্ট বহু-ফিল্ডে।

লুকানো কনস্ট্রেইন্ট: ইনডেক্সিং, অ্যাম্প্লিফিকেশন, এবং হট পার্টিশন

পারফরম্যান্স পরামর্শ তখনও বিচ্যুত হয় যখন মডেল উপেক্ষা করে:

• ইন্ডেক্সিং সীমা ও ট্রেড-অফ: সেকেন্ডারি ইনডেক্স রিড দ্রুত করে কিন্তু রাইটে খরচ ও স্টোরেজ বাড়ায়। কিছু সিস্টেমে কম্পোজিট ইনডেক্স, ইনডেক্স বিল্ড টাইম, বা অনলাইন ইনডেক্স পরিবর্তনের সীমা আছে।
• রাইট অ্যাম্প্লিফিকেশন: LSM-ভিত্তিক ইঞ্জিনগুলি “সরল রাইট” কে পটভূমিতে উল্লেখযোগ্য কমপ্যাকশন কাজ ধরে রূপান্তর করে, যা ধারাবাহিক ইনজেশনের সময় গুরুত্বপূর্ণ।
• হট পার্টিশন: শার্ডিং বা পার্টিশনিং ছাড়া ও ট্রাফিক যদি ছোট কী রেঞ্জে কেন্দ্রীভূত হয় (উদাহরণ: সবচেয়ে নতুন টেন্যান্ট, আজকের তারিখ, একটি জনপ্রিয় আইটেম), তাহলে বটলনেক রয়ে যায়।

ক্যাশ আচরণ ও কুয়েরি আকৃতি

একটি LLM ধরে নেবে ক্যাশ আপনাকে বাঁচাবে, কিন্তু ক্যাশ কেবল ভবিষ্যদ্বাণীকৃত অ্যাক্সেস প্যাটার্নে সহায়ক। বড় রেঞ্জ স্ক্যান, নন-ইন্ডেক্সফিল্ডে সোর্ট, বা অ্যাড-হক ফিল্টারগুলো ক্যাশ মিস করে ডিস্ক/CPU-এ চাপ দেয়।

কুয়েরি আকৃতির ক্ষুদ্র পরিবর্তন (যেমন, OFFSET পেজিনেশন বনাম কীসেট পেজিনেশন) পারফরম্যান্স ফলাফল উল্টে দিতে পারে।

একটি ছোট বেঞ্চমার্ক পরিকল্পনা (অনুমানের থেকে ভাল)

জেনেরিক “X তে দ্রুত” বিশ্বাস করার বদলে একটি হালকা, প্রোডাক্ট-আকৃতির টেস্ট চালান:

1. ৩–৫ টি প্রতিনিধিত্বমূলক কুয়েরি বেছে নিন (সহজ + ওয়ার্সট-কেস ফিল্টার/সোর্ট) এবং ১–২ রাইট প্যাটার্ন (steady + burst)।
2. বাস্তবসম্মত ডেটা ভলিউম ব্যবহার করুন (কমপক্ষে মেমোরি অতিক্রম করার জন্য; স্কিউ ও হট কী শামিল করুন)।
3. p50/p95/p99 লেটেন্সি এবং রিড/রাইট আলাদা করে থ্রুপুট মাপুন।
4. ইন্ডেক্স ভ্যারিয়েন্ট পরীক্ষা করুন (কোন ইনডেক্স নেই, মিনিমাল ইনডেক্স, “আইডিয়াল” ইনডেক্স) এবং রাইট ওভারহেড নোট করুন।
5. প্রত্যাশিত পিকের কাছাকাছি কনকারেন্সি নিয়ে চালান এবং CPU, ডিস্ক, কমপ্যাকশন, লক/ট্রানজ্যাকশন মেট্রিক নজর করুন।

বেঞ্চমার্ক সবকিছু পূর্বাভাস দেবে না, কিন্তু দ্রুতই প্রকাশ করবে LLM-এর পারফরম্যান্স অনুমান বাস্তবতার সাথে মিলে কিনা।

ব্যর্থতার মোড ৬: অপারেশনাল ও খরচগত উপেক্ষা

LLM কাগজে ফিট (ডেটা মডেল, কুয়েরি প্যাটার্ন, স্কেল বল্ল্যাড) এর জন্য অপ্টিমাইজ করে—পরে যা একটি ডেটাবেসকে উৎপাদনে টিকতেই রাখে তা: অপারেশন, ব্যর্থতা পুনরুদ্ধার, এবং প্রকৃত মাসিক বিল—এইগুলো প্রায় উপেক্ষা করে।

লুকানো কাজ: ব্যাকআপ, রিকভারি, এবং মাইগ্রেশন

একটি ডেটাবেস সুপারিশ তখনই সম্পূর্ণ যখন এটি মৌলিক প্রশ্নগুলোর উত্তর দেয়: কনসিস্টেন্ট ব্যাকআপ কিভাবে নেবেন? কত দ্রুত রিস্টোর করতে পারবেন? রিজিয়ন জুড়ে ডিজাস্টার রিকভারি প্ল্যান কী?

LLM পরামর্শ প্রায়ই এসব বিস্তারিত বাদ দিয়ে দেয়, বা ধরে নেয় এগুলো “বিল্ট-ইন”।

মাইগ্রেশনও আরেকটি ব্লাইন্ডস্পট। পরে ডেটাবেস বদলানো ব্যয়বহুল ও ঝুঁকিপূর্ণ (স্কিমা পরিবর্তন, ডুয়াল রাইট, ব্যাকফিল, কুয়েরি রিরাইট)। যদি আপনার প্রোডাক্ট বিবর্তিত হওয়ার সম্ভাবনা থাকে, “শুরু করা সহজ” যথেষ্ট নয়—আপনাকে বাস্তবসম্মত মাইগ্রেশন পথ দরকার।

অবজার্ভেবিলিটি প্রোডাক্টের অংশ

টিম শুধু একটি ডেটাবেসই নয়—তাকে অপারেট করতেও হবে।

যদি সুপারিশ ধীর কুয়েরি লগ, মেট্রিকস, ড্যাশবোর্ড, ট্রেসিং হুক, এবং অ্যালার্টিং উপেক্ষা করে, আপনি ততক্ষণ বাদ পরবেন যতক্ষণ না ব্যবহারকারীরা অভিযোগ করে। অপারেশনাল টুলিং ম্যানেজড বনাম সেল্ফ-হোস্টেড সেটআপে এবং ভেন্ডরের মধ্যে ব্যাপকভাবে ভিন্ন।

মোট খরচ কেবল ঘণ্টা রেট নয়

LLM প্রায়শই ইনস্ট্যান্স সাইজে ফোকাস করে এবং প্রকৃত গুণগুলি ভুলে যায়:

• স্টোরেজ বৃদ্ধি ও রিটেনশন পলিসি
• IOPS/থ্রুপুট প্রাইসিং ও বার্স্ট সীমা
• HA/রিড স্কেলের জন্য রিপ্লিকা
• অন-কল সময়, ইনসিডেন্ট রেসপন্স, এবং সাপোর্ট প্ল্যান

টিমের সাথে ডেটাবেস মিলান

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

ব্যর্থতার মোড ৭: অতিরিক্ত জটিল মাল্টি-ডেটাবেস ডিজাইন

LLM কখনও কখনও “সবকিছু একসাথে সমাধান” করার চেষ্টা করে একটি স্ট্যাক প্রস্তাব করে: Postgres লেনদেনের জন্য, Redis ক্যাশিংয়ের জন্য, Elasticsearch সার্চের জন্য, Kafka + ClickHouse অ্যানালিটিকসের জন্য, এবং গ্রাফ ডাটাবেস “জাস্ট ইন কেস।” এটি ই impres sive শোনাতে পারে, কিন্তু প্রায়ই এটি প্রারম্ভিকভাবে অতিরিক্ত ডিজাইন যা ভ্যালু তুলে না—বিশেষত প্রোডাক্টের প্রথম পর্যায়ে।

কেন পরামর্শ ভুল হয়

মাল্টি-ডেটাবেস ডিজাইন নিরাপদ হেজের মতো মনে হয়: প্রতিটি টুল একটি কাজের জন্য “শ্রেষ্ঠ”। লুকানো খরচ প্রতিটি অতিরিক্ত ডেটাস্টোরের সঙ্গে বাড়ে: ডেপ্লয়, মনিটরিং, ব্যাকআপ, মাইগ্রেশন, অ্যাক্সেস কন্ট্রোল, ইনসিডেন্ট রেসপন্স, এবং নতুন ফেইল-মোড।

টিম তারপর প্লাম্বিং রক্ষণাবেক্ষণে সময় ব্যয় করে ফিচার শিপ করার বদলে।

কখন পলিগ্লট প্রসিস্টেন্স যুক্তিসঙ্গত

দ্বিতীয় (বা তৃতীয়) ডেটাবেস সাধারণত যুক্তিসঙ্গত যখন স্পষ্ট, পরিমাপযোগ্য প্রয়োজন আছে যা প্রধান ডেটাবেসটি অপরিসীম ব্যথা ছাড়াই মেটাতে পারে না, উদাহরণস্বরূপ:

• সার্চ কোয়ালিটি/লেটেন্সি চাহিদা যা প্রধান DB পূরণ করতে পারে না
• অ্যানালিটিকস ওয়ার্কলোড যা ট্রানজ্যাকশনারী পারফরম্যান্সকে উল্লেখযোগ্যভাবে অবনতি করে
• স্কেল প্যাটার্নস যা আলাদা স্টোরেজ বা ইনডেক্সিং মডেল প্রয়োজন করে

যদি আপনি নির্দিষ্ট কুয়েরি, লেটেন্সি টার্গেট, খরচ সীমা, বা অপারেশনাল ঝুঁকি নাম করতে না পারেন যা বিভাজনকে চালায়, তাহলে এটি সম্ভবত আগেই।

ক্রস-স্টোর কনসিস্টেন্সি ও ডুপ্লিকেশন জাল

একবার ডেটা একাধিক জায়গায় থাকলে, কঠিন প্রশ্ন আসে: কোন স্টোর সোর্স অব ট্রুথ? কিভাবে রেকর্ডগুলো রিট্রাই, আংশিক ব্যর্থতা, এবং ব্যাকফিলের সময় সিঙ্ক রাখবেন?

ডুপ্লিকেট ডেটাও মানে ডুপ্লিকেট বাগ—স্টেল সার্চ ফলাফল, মেলান ইউজার কাউন্ট, এবং “আপনি কোন ড্যাশবোর্ড দেখছেন তার উপর নির্ভর করে” ধরনের মিটিং।

একটি ব্যবহারিক সিদ্ধান্ত নিয়ম

কোর ট্রানজ্যাকশন ও রিপোর্টিংয়ের জন্য একটি জেনারেল-পারপাস ডাটাবেস দিয়ে শুরু করুন। শুধুমাত্র তখনই একটি পারপাস-বিল্ট স্টোর যোগ করুন যখন আপনি (1) দেখাতে পারেন যে বর্তমান সিস্টেম একটি চাহিদার বিরুদ্ধে ব্যর্থ হচ্ছে এবং (2) সিঙ্ক, কনসিস্টেন্সি, এবং রিকভারি জন্য একটি মালিকানা মডেল নির্ধারণ করতে পারেন।

জটিলতা নয়—এগজিট হ্যাচ রাখুন।

LLM ডেটাবেস পরামর্শ যাচাই করার ব্যবহারিক চেকলিস্ট

LLM-গুলো প্রথম ড্রাফট ডেটাবেস সুপারিশ তৈরিতে সাহায্য করতে পারে, কিন্তু আপনি এটি হাইপোথেসিস হিসেবে বিবেচনা করবেন। সুপারিশটি গ্রহণ করার আগে নিচের চেকলিস্ট ব্যবহার করে যাচাই (বা প্রত্যাখ্যান) করুন।

১) ইনপুটগুলো স্পষ্ট করুন (লিখে রাখুন)

প্রোম্পটকে স্পষ্ট রিকোয়ারমেন্টে রূপান্তর করুন। যদি আপনি এটা স্পষ্টভাবে লিখতে না পারেন, মডেল সম্ভবত অনুমান করেছে।

• প্রোডাক্টের কোর ওয়ার্কলোড কী: OLTP, অ্যানালিটিকস, সার্চ, টাইম-সিরিজ, মেসেজিং?
• প্রত্যাশিত স্কেল: ব্যবহারকারী, রাইট/রিড/সেকেন্ড, স্টোরেজ বৃদ্ধি, পিক-টু-এভরেজ।
• ননফাংশনাল চাহিদা: আপটাইম, মাল্টি-রিজিয়ন, কমপ্লায়েন্স, বাজেট, টিম স্কিল।

২) ডেটা মডেল ও মূল কুয়েরিগুলো মডেল করুন

বাস্তব এন্টিটি ও সম্পর্কগুলো খসড়া করুন (এমনকি একটি স্কেচ)। তারপর আপনার শীর্ষ এক্সেস প্যাটার্নগুলো তালিকাভুক্ত করুন।

• শীর্ষ ১০ টি রিড ও রাইট কি কি?
• কোন কুয়েরি পিকে পিক সময়ে দ্রুত হতে হবে?
• কী কী ইনডেক্স করা, জয়েন করা, অগ্রিগেট করা, বা সার্চ করা আবশ্যক?

৩) গ্রহণযোগ্যতার পরীক্ষাগুলো সংজ্ঞায়িত করুন (সাফল্যের মাপকাঠি)

“দ্রুত ও নির্ভরযোগ্য হওয়া উচিত” কে পরিমাপযোগ্য পরীক্ষায় রূপান্তর করুন।

• শীর্ষ কুয়েরিগুলোর জন্য লেটেন্সি ও থ্রুপুট লক্ষ্য (p95/p99)
• কনসিস্টেন্সি ও ট্রানজ্যাকশন প্রয়োজনীয়তা (কী অ্যাটোমিক হতে হবে?)
• ব্যর্থতার কেস: নোড লস, নেটওয়ার্ক পার্টিশন, রিজিয়ন ফেইলওভার, ব্যাকআপ/রিস্টোর সময়

৪) হালকা-ওজন প্রুফ-অফ-কনসেপ্ট চালান

টয় না—বাস্তব ডেটা আকৃতি ও কুয়েরি মিশ্রণ ব্যবহার করুন। প্রতিনিধি ডেটাসেট লোড করুন, লোডের অধীনে কুয়েরি চালান, এবং মাপুন।

যদি LLM একাধিক ডেটাবেস প্রস্তাব করে, প্রথমে সবচেয়ে সাধারণ এক-ডেটাবেস অপশনটিকে পরীক্ষা করুন, তারপর দেখান কেন বিভক্ত করা প্রয়োজন।

আপনি যদি এই ধাপ দ্রুত করতে চান, একটি ব্যবহারিক উপায় হল প্রোডাক্টের সেই অংশটি প্রোটোটাইপ করা যা ডেটাবেস সিদ্ধান্ত চালায় (কয়েকটি কোর এন্টিটি + টপ এন্ডপয়েন্ট + সবচেয়ে গুরুত্বপূর্ণ কুয়েরি)। প্ল্যাটফর্মগুলো যেমন Koder এখানে সাহায্য করতে পারে: আপনি চ্যাটে ওয়ার্কফ্লো বর্ণনা করে একটি কার্যকরী ওয়েব/ব্যাকএন্ড অ্যাপ (সাধারণত React + Go + PostgreSQL) জেনারেট করতে পারেন, এবং আপনি দ্রুত স্কিমা, ইনডেক্স, ও কুয়েরি আকৃতি নিয়ে পুনরাবৃত্তি করতে পারেন। প্ল্যানিং মোড, স্ন্যাপশট, এবং রোলব্যাকের মতো ফিচারগুলো বিশেষভাবে উপকারী যখন আপনি ডেটা মডেল ও মাইগ্রেশনের সঙ্গে পরীক্ষা-নিরীক্ষা করছেন।

৫) সিদ্ধান্ত ও “চেঞ্জ ট্রিগার” ডকুমেন্ট করুন

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