CRUD কী? Create, Read, Update, Delete ব্যাখ্যা
CRUD মানে create, read, update ও delete — সংরক্ষিত ডেটা নিয়ে একটি অ্যাপ যে চারটি মৌলিক কাজ করে। একজন নতুন গ্রাহক যোগ করা হলো create, গ্রাহকদের তালিকা দেখা হলো read, তাদের ফোন নম্বর বদলানো হলো update, আর তাদের সরিয়ে ফেলা হলো delete। বেশিরভাগ ব্যবসায়িক অ্যাপ — CRM, বুকিং সিস্টেম, ইনভেন্টরি ট্র্যাকার, অ্যাডমিন প্যানেল — মূলত CRUD, সঙ্গে নিয়ম ও একটি ভালো লেআউট।
AI দিয়ে বানালে এটি কেন গুরুত্বপূর্ণ
CRUD সেই শব্দভাণ্ডার, যা একটি অস্পষ্ট অ্যাপের ধারণাকে নির্দিষ্ট অনুরোধে রূপ দেয়। “আমাদের সরবরাহকারীদের পরিচালনার একটি অ্যাপ” বললে AI অনুমান করতে বাধ্য হয়। “সরবরাহকারীদের তৈরি, তালিকা, সম্পাদনা ও মুছে ফেলার সুযোগ দাও, এই ফিল্ডগুলোসহ” বললে সে ঠিক কোন স্ক্রিন, ডেটাবেস অপারেশন ও সার্ভার রুট বানাবে তা জানে।
এটি পরীক্ষার জন্য একটি চেকলিস্টও দেয়। আপনার অ্যাপের প্রতিটি ধরনের রেকর্ডের জন্য চারটি প্রশ্ন করতে পারেন: আমি কি একটি যোগ করতে পারি, দেখতে পারি, একটি বদলাতে পারি এবং একটি সরাতে পারি — এবং শুধু সঠিক মানুষই প্রতিটি কাজ করতে পারে কি না? অনেক AI-তৈরি অ্যাপ রেকর্ড তৈরি করতে পারে কিন্তু সম্পাদনা করতে পারে না, অথবা যে কেউ যেকোনো কিছু মুছতে পারে।
একটি দৈনন্দিন উপমা: একটি রেসিপি কার্ডের বাক্স
একটি রান্নাঘরের তাকে রাখা রেসিপি কার্ডের বাক্সের কথা ভাবুন।
- Create: একটি নতুন কার্ড লিখে তা ফাইল করা।
- Read: বাক্সের মধ্য দিয়ে ওল্টানো, বা লাসাগনার কার্ডটি বের করা।
- Update: “২০০ গ্রাম পনির” কেটে “২৫০ গ্রাম” লেখা।
- Delete: একটি কার্ড বের করে ফেলে দেওয়া।
এবার নিয়ম যোগ করুন: শুধু প্রধান রাঁধুনি কার্ড ফেলতে পারবেন, প্রতিটি কার্ডের একটি শিরোনাম থাকতে হবে, এবং কেউ একই নামে দুটি কার্ড ফাইল করতে পারবে না। এটিই যাচাইকরণ ও অনুমতিসহ একটি CRUD অ্যাপ — বেশিরভাগ বাস্তব অ্যাপ ঠিক এমনই।
প্রতিটি স্তরে CRUD কীভাবে দেখা যায়
প্রতিটি অপারেশন স্ক্রিন, সার্ভার ও ডেটাবেস — তিন জায়গায় দেখা যায়। পাশাপাশি দেখলে অ্যাপ কীভাবে বানানো হয় তা অনেক স্পষ্ট হয়।
| অপারেশন | স্ক্রিনে | API অনুরোধ (REST) | ডেটাবেসে SQL |
|---|---|---|---|
| Create | একটি “New” বোতাম ও একটি ফর্ম | POST /api/suppliers | INSERT |
| Read | সার্চ ও ফিল্টারসহ একটি তালিকা; একটি বিস্তারিত পেজ | GET /api/suppliers ও GET /api/suppliers/42 | SELECT |
| Update | একটি “Edit” ফর্ম বা ইনলাইন সম্পাদনা | PUT বা PATCH /api/suppliers/42 | UPDATE |
| Delete | একটি নিশ্চিতকরণসহ “Delete” বোতাম | DELETE /api/suppliers/42 | DELETE (বা সারিটিকে মুছে যাওয়া হিসেবে চিহ্নিত করা) |
স্ক্রিন হলো ফ্রন্টএন্ড, API অনুরোধ হলো ফ্রন্টএন্ড কীভাবে ব্যাকএন্ডের সাথে কথা বলে, আর SQL হলো ব্যাকএন্ড কীভাবে ডেটাবেসের সাথে কথা বলে। এই শব্দগুলো নতুন হলে দেখুন API কী ও ডেটাবেস কী।
একটি বাস্তব উদাহরণ: একটি সরঞ্জাম ধার দেওয়ার ট্র্যাকার
একটি স্কুলের মিডিয়া বিভাগ ছাত্রছাত্রীদের ক্যামেরা ও মাইক্রোফোন ধার দেয়, এবং তারা প্রায়ই হিসাব হারিয়ে ফেলে। তাদের একটি সহজ অ্যাপ দরকার।
রেকর্ড। দুই ধরনের জিনিস: সরঞ্জাম (নাম, ধরন, সিরিয়াল নম্বর, অবস্থা) এবং ধার (কোন সরঞ্জাম, কোন ছাত্র, কবে নেওয়া, কবে ফেরত দিতে হবে, কবে ফেরত এসেছে)।
সরঞ্জামের CRUD:
- Create: স্টাফ একটি নতুন ক্যামেরা তার সিরিয়াল নম্বরসহ যোগ করে। নিয়ম: সিরিয়াল নম্বর অনন্য হতে হবে।
- Read: সব সরঞ্জামের একটি তালিকা, ধরন ও “এখন পাওয়া যাচ্ছে” দিয়ে ফিল্টারযোগ্য; একটি বিস্তারিত পেজ যেখানে একটি আইটেমের ধারের ইতিহাস দেখা যায়।
- Update: অবস্থা “মেরামত দরকার”-এ বদলানো।
- Delete: সাধারণত আসল মুছে ফেলা নয়। যদি ৩০টি অতীত ধার থাকা একটি ক্যামেরা মুছে ফেলা হয়, সেই ধার-রেকর্ডগুলোর সংযোগ হারিয়ে যায়। বরং এটিকে “অবসরপ্রাপ্ত” চিহ্নিত করুন, যাতে এটি পাওয়া যাওয়া তালিকা থেকে সরে যায় কিন্তু ইতিহাস থেকে যায়। একে বলে soft delete।
ধারের CRUD:
- Create: একজন ছাত্রকে একটি সরঞ্জাম ধার দেওয়া। নিয়ম: যে সরঞ্জাম আগে থেকেই ধার দেওয়া আছে তা আবার ধার দেওয়া যাবে না।
- Read: “মেয়াদ পেরিয়ে যাওয়া ধার” — একটি তালিকা, যেখানে ফেরতের তারিখ পেরিয়ে গেছে এবং ফেরত দেওয়ার তারিখ নেই।
- Update: সরঞ্জাম ফিরে এলে ফেরতের তারিখ রেকর্ড করা।
- Delete: শুধু স্টাফ, ভুলভাবে প্রবেশ করা ধারের জন্য।
অনুমতি। ছাত্রেরা কী পাওয়া যাচ্ছে তা পড়তে পারে; শুধু স্টাফ তৈরি, সম্পাদনা বা মুছতে পারে। এই যাচাইগুলো শুধু বোতাম লুকিয়ে নয়, সার্ভারে চলে।
এটুকুই পুরো অ্যাপ। আকর্ষণীয় অংশগুলো — একই জিনিস দুবার ধার না দেওয়া, মেয়াদ পেরোনো তালিকা, প্রতি আইটেমের ইতিহাস — সাধারণ CRUD-এর ওপরের নিয়ম ও কোয়েরি।
মূল শব্দ
- রেকর্ড (সারি): একটি আইটেম, যেমন একজন সরবরাহকারী বা একটি ধার।
- Entity / resource: এক ধরনের রেকর্ড, যেমন “সরবরাহকারী”। প্রতিটির সাধারণত নিজস্ব টেবিল ও নিজস্ব CRUD স্ক্রিন সেট থাকে।
- Validation: ইনপুটের যাচাই — আবশ্যক ফিল্ড, সঠিক ইমেইল, ধনাত্মক পরিমাণ। সুবিধার জন্য ফর্মে এবং নিরাপত্তার জন্য সার্ভারে — দুই জায়গাতেই করুন।
- Soft delete: সম্পূর্ণ সরানোর বদলে রেকর্ডকে মুছে যাওয়া বা আর্কাইভ হিসেবে চিহ্নিত করা, যাতে ইতিহাস ও সংযোগ টিকে থাকে।
- Pagination: একটি দীর্ঘ তালিকা একবারে এক পাতা করে দেখানো, যাতে অ্যাপ দ্রুত থাকে।
- Audit log: কে কী তৈরি, বদলানো বা মুছেছে এবং কখন, তার রেকর্ড।
- Admin panel: স্টাফদের জন্য একটি অ্যাপের ডেটা পরিচালনার CRUD স্ক্রিনের সেট।
সাধারণ ভুল ও ভুল ধারণা
- চারটির একটি ভুলে যাওয়া। অনেক অ্যাপ শুধু create ও read নিয়ে আসে, edit ছাড়া, তাই প্রতিটি বানানভুলে মুছে আবার লিখতে হয়। প্রতিটি entity-র জন্য চারটিই যাচাই করুন।
- মুছলে যা ভেঙে যায়। বিল থাকা একজন গ্রাহককে মুছলে এতিম ইনভয়েস থেকে যেতে পারে বা ইতিহাস মুছে যেতে পারে। প্রতি entity-র জন্য সিদ্ধান্ত নিন: মোছা বন্ধ করা, soft delete, নাকি সংশ্লিষ্ট রেকর্ডও মোছা।
- শুধু ইন্টারফেসে অনুমতি। Delete বোতাম লুকালেই কেউ
DELETEঅনুরোধ পাঠানো আটকায় না। সার্ভারকে যাচাই করতে হবে কে অনুরোধ করছে। - ID দেখে আপডেট, মালিকানা যাচাই ছাড়া। যদি ব্যবহারকারী A URL-এর একটি সংখ্যা বদলে
/api/notes/42সম্পাদনা করতে পারে, সে ব্যবহারকারী B-র নোট সম্পাদনা করতে পারে। প্রতিটি update ও delete নিশ্চিত করতে হবে যে রেকর্ডটি অনুরোধকারীর। - মুছতে নিশ্চিতকরণ না থাকা। একটি ভুল ট্যাপে ডেটা ধ্বংস হওয়া উচিত নয়। একটি নিশ্চিতকরণ ধাপ বা আনডো রাখুন।
- “CRUD মানে সাধারণ, তাই বানানোর যোগ্য নয়।” অনেক মূল্যবান পণ্য CRUD অ্যাপ, যা একটি কাজের প্রবাহের সাথে একটি সাধারণ টুলের চেয়ে ভালো মেলে।
আপনার AI বিল্ডারের কাছে কী চাইবেন
প্রতিটি entity-র জন্য একবারে একটি করে এই প্যাটার্নটি ব্যবহার করুন:
একটি suppliers ফিচার বানাও, যাতে তালিকা, তৈরি, সম্পাদনা ও মুছে ফেলা থাকে। ফিল্ড: নাম (আবশ্যক), যোগাযোগের ইমেইল (সঠিক ইমেইল), ফোন, ক্যাটাগরি (food, packaging, cleaning-এর একটি), নোট। নাম দিয়ে সার্চ ও ক্যাটাগরি দিয়ে ফিল্টারসহ তালিকা, প্রতি পাতায় ২০টি। মুছে ফেলার আগে নিশ্চিত করো; সরবরাহকারীর অর্ডার থাকলে মোছার বদলে আর্কাইভ করো। শুধু লগইন করা স্টাফ তৈরি, সম্পাদনা বা আর্কাইভ করতে পারবে — এটি সার্ভারে প্রয়োগ করো।
তারপর অনুমতিপ্রাপ্ত ব্যবহারকারী ও যার অনুমতি নেই এমন ব্যবহারকারী হিসেবে চারটি অপারেশনই পরীক্ষা করুন। একটি entity কাজ করলে পরেরটি যোগ করুন। অভ্যন্তরীণ টুল কীভাবে বানাবেন দেখায় কীভাবে CRUD স্ক্রিন একটি পূর্ণাঙ্গ অ্যাডমিন অ্যাপে পরিণত হয়, এবং Postgres কী ব্যাখ্যা করে এই বেশিরভাগ অ্যাপ যে ডেটাবেসের ওপর থাকে সেটি কী।
Mythex-এ CRUD অ্যাপ
CRUD অ্যাপ হলো AI অ্যাপ বিল্ডাররা যা সবচেয়ে ভালো করে, এবং Mythex-ও এর ব্যতিক্রম নয়। চ্যাটে entity ও তার ফিল্ড চাইলে Mythex প্রজেক্টে একটি Postgres ডেটাবেস যুক্ত করে, টেবিল তৈরি করে এবং একটি লাইভ প্রিভিউতে তালিকা, ফর্ম ও বিস্তারিত স্ক্রিন বানায়; এরপর আপনি /test চালিয়ে ফ্লো যাচাই করতে পারেন। ডকসে একটি স্টার্টার প্রম্পটসহ CRUD অ্যাপ রেসিপি আছে, এবং শুরু করার ভালো জায়গা অভ্যন্তরীণ টুল বিল্ডার ও ড্যাশবোর্ড টেমপ্লেট।
প্রশ্নোত্তর
CRUD-এর পুরো নাম কী?
CRUD মানে create, read, update ও delete: নতুন রেকর্ড যোগ করা, রেকর্ড দেখা, একটি রেকর্ড বদলানো ও একটি রেকর্ড সরানো। ডেটা সংরক্ষণ করে এমন প্রায় প্রতিটি অ্যাপ এই চারটি অপারেশন দিয়ে গড়া।
CRUD অ্যাপ কী?
CRUD অ্যাপ এমন একটি অ্যাপ, যার মূল কাজ ফর্ম, তালিকা ও বিস্তারিত পেজের মাধ্যমে রেকর্ড পরিচালনা করা, যেমন একটি CRM, একটি ইনভেন্টরি ট্র্যাকার, একটি বুকিং অ্যাডমিন বা একটি জব বোর্ডের ব্যাক অফিস। বেশিরভাগ অভ্যন্তরীণ টুল ও অ্যাডমিন প্যানেল CRUD অ্যাপ।
CRUD কীভাবে REST API-র সাথে সম্পর্কিত?
একটি সাধারণ REST API-তে create-এর জন্য POST অনুরোধ, read-এর জন্য GET, update-এর জন্য PUT বা PATCH, এবং delete-এর জন্য DELETE ব্যবহৃত হয়। এরপর ব্যাকএন্ড সংশ্লিষ্ট ডেটাবেস অপারেশন চালায়: INSERT, SELECT, UPDATE বা DELETE।
CRUD অ্যাপ কি এতটা সাধারণ যে তার মূল্য নেই?
না। অনেক কার্যকর ব্যবসায়িক সফটওয়্যার ভালো নিয়ম, অনুমতি ও রিপোর্টসহ CRUD। মূল্য আছে ডেটাকে ভালোভাবে মডেল করায় ও কাজের প্রবাহের সাথে মেলাতে, অস্বাভাবিক প্রযুক্তিতে নয়।