ডেটাবেস কী? যারা অ্যাপ বানাচ্ছেন তাদের জন্য একটি গাইড

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

AI দিয়ে তৈরি করলে কেন গুরুত্বপূর্ণ

AI দিয়ে যারা তৈরি করেন তাদের সবচেয়ে সাধারণ বিস্ময় হলো এমন একটি অ্যাপ, যা দেখতে সম্পূর্ণ মনে হয় কিন্তু সব ভুলে যায়। আপনি একজন গ্রাহক যোগ করলেন, পেজ রিফ্রেশ করলেন, আর তিনি উধাও। এর মানে সাধারণত অ্যাপটি ডেটা ডেটাবেসে না রেখে ব্রাউজারের মেমরিতে রাখছিল।

ডেটাবেস এমন অনেক গুরুত্বপূর্ণ সিদ্ধান্তেরও ঠিকানা, আপনি তা বুঝুন বা না বুঝুন:

• আপনি কী রেকর্ড করেন। বুকিংয়ের স্ট্যাটাস সংরক্ষণ না করলে কোন বুকিং বাতিল হয়েছে তা দেখাতে পারবেন না।
• কীভাবে জিনিসগুলো যুক্ত। একজন গ্রাহকের অনেক বুকিং থাকতে পারে কি না, বা একটি বুকিংয়ে অনেক সেবা থাকতে পারে কি না — এটি পুরো অ্যাপের গড়ন ঠিক করে।
• কে কী দেখতে পারবে। গোপনীয়তার বেশিরভাগ ভুল হয় কোন ব্যবহারকারী কোন রেকর্ড পড়তে পারবেন তা নিয়ে।

ডেটাবেস নিজে ডিজাইন করা আপনার দরকার নেই। তবে মৌলিক বিষয়গুলো বুঝলে আপনি আপনার ডেটা স্পষ্টভাবে বর্ণনা করতে পারবেন এবং সমস্যা আগে ধরতে পারবেন।

একটি দৈনন্দিন উপমা

একটি ছোট অফিসের সুগঠিত ফাইল কেবিনেটের কথা ভাবুন।

প্রতিটি ড্রয়ারে এক ধরনের জিনিস থাকে: একটি ড্রয়ার ক্লায়েন্টদের জন্য, একটি অ্যাপয়েন্টমেন্টের জন্য, একটি ইনভয়েসের জন্য। প্রতিটি ড্রয়ারের ভেতরের প্রতিটি ফোল্ডার একই ফরম্যাট মানে, একই ফিল্ড পূরণ করা। প্রতিটি ফোল্ডারের একটি অনন্য রেফারেন্স নম্বর থাকে, আর যখন একটি ইনভয়েস কোনো ক্লায়েন্টের হয়, তখন ইনভয়েসের ফোল্ডারে সেই ক্লায়েন্টের পুরো ফাইলের ফটোকপি না রেখে তার নম্বর লেখা থাকে।

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

একটি বাস্তব উদাহরণ: একটি সেলুন বুকিং অ্যাপ

ধরুন আপনি AI-কে একটি হেয়ার সেলুনের জন্য বুকিং সাইট বানাতে বললেন। একটি যুক্তিসংগত ডেটাবেসে চারটি টেবিল থাকবে।

services

staff

customers

bookings

bookings টেবিলটি দেখুন। এটি প্রতিটি বুকিংয়ে Lena-র নাম ও ফোন নম্বর কপি করে না; এটি রাখে customer_id = 101। Lena যদি ফোন নম্বর বদলান, সেটি এক জায়গাতেই বদলায় এবং প্রতিটি বুকিং নতুনটি দেখায়। রিলেশনাল ডেটাবেসের মূল ধারণা এটাই: প্রতিটি তথ্য একবার সংরক্ষণ করুন এবং তার সঙ্গে যুক্ত হন।

একই গঠন কার্যকর প্রশ্নের উত্তরও দেয়:

• “শুক্রবার Omar-এর কোন স্লট খালি?” — সেদিনের Omar-এর বুকিংগুলো দেখুন।
• “এই মাসে কালার সেবা থেকে কত আয় হয়েছে?” — bookings-কে services-এর সঙ্গে জোড়া দিয়ে দাম যোগ করুন।
• “কোন গ্রাহকরা ৯০ দিনে বুকিং করেননি?” — গ্রাহকদের সর্বশেষ বুকিংয়ের সঙ্গে তুলনা করুন।

সাধারণ পরিভাষা ব্যাখ্যা

ডেটাবেসের ধরন

একজন উদ্যোক্তা বা ছোট ব্যবসা প্রথমে যা বানায় তার প্রায় সবকিছুর জন্য একটি রিলেশনাল ডেটাবেসই নিরাপদ ডিফল্ট।

ডেটাবেস আপনার অ্যাপের কোথায় বসে

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

এই মাঝের ধাপটি গুরুত্বপূর্ণ। ব্রাউজার যদি পূর্ণ অধিকার নিয়ে সরাসরি ডেটাবেস কোয়েরি করতে পারত, তাহলে যে কেউ ডেভেলপার টুলস খুলে সবকিছু পড়তে পারত।

সাধারণ ভুল ও ভুল ধারণা

• ডেটা শুধু ব্রাউজারে রাখা। ব্রাউজার স্টোরেজ (যেমন localStorage) একটি ডিভাইস ও একটি ব্রাউজারে থাকে। একটি মনে রাখা ফিল্টারের জন্য এটি ঠিক আছে, অর্ডারের জন্য নয়।
• সব কিছু এক টেবিলে ঠুসে দেওয়া। একটি একক “bookings” টেবিলে প্রতিটি সারিতে গ্রাহকের নাম, ফোন ও সেবার দাম কপি করে রাখলে দ্রুত গরমিল হয়ে যায়।
• পাসওয়ার্ড সাদা টেক্সটে রাখা। পাসওয়ার্ড হ্যাশ করে রাখতে হবে, কখনো পড়া যায় এমনভাবে নয়। দেখুন অথেনটিকেশন কী।
• ডেটার উপর কোনো নিয়ম না থাকা। প্রয়োজনীয় ফিল্ড ও অনন্যতার নিয়ম ছাড়া তারিখহীন বুকিং ও ডুপ্লিকেট গ্রাহক আসবে।
• মোছা নিয়ে ভাবতে ভুলে যাওয়া। গ্রাহক মুছলে তার বুকিংও মুছবে, নাকি রাখা হবে, নাকি আটকে যাবে — সিদ্ধান্ত নিন।
• পরীক্ষার জন্য প্রোডাকশন ডেটা ব্যবহার। ঝুঁকিপূর্ণ পরিবর্তন আগে নিরাপদ কোথাও পরীক্ষা করুন এবং ব্যাকআপ রাখুন।
• স্প্রেডশিটকে চিরকালের ডেটাবেস ভাবা। শুরুতে স্প্রেডশিট দারুণ, কিন্তু একসঙ্গে অনেক ব্যবহারকারী ও অনুমতি সামলাতে এটি কষ্ট পায়। দেখুন কীভাবে স্প্রেডশিটকে অ্যাপে রূপান্তর করবেন।

আপনার AI বিল্ডারের কাছে কী চাইবেন

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

Mythex-এ ডেটাবেস

যখন আপনার অ্যাপের ডেটা সংরক্ষণ করতে হয়, Mythex প্রজেক্টে একটি নিবেদিত Postgres ডেটাবেস যোগ করে — চ্যাটে বলতে পারেন (“waitlist sign-up গুলো একটি ডেটাবেসে রাখো”), অথবা /database কমান্ড ব্যবহার করতে পারেন। সংযোগের তথ্য স্বয়ংক্রিয়ভাবে আপনার অ্যাপে যায় এবং এজেন্ট টেবিলগুলো বানায়। পাঁচ মিনিট অলস থাকলে ডেটাবেস ঘুমিয়ে পড়ে এবং পরবর্তী অনুরোধে জেগে ওঠে; প্রকাশিত ব্যবহারের খরচ ধরা হয় জেগে থাকা সময়ের জন্য, বিল্ড করার একই ক্রেডিট ব্যালেন্স থেকে। এটি Free ও Pro — দুই প্ল্যানেই পাওয়া যায়। বিস্তারিত দেখুন ডেটাবেস ডকুমেন্টেশন, আর অ্যাপ টেমপ্লেট-এ ডেটা-ভিত্তিক শুরুর জায়গা আছে।

প্রশ্নোত্তর