অ্যাডমিন প্যানেল ডাটাবেস নামকরণ: পড়তে সুবিধাজনক নিয়ম

কেন নামগুলো ঠিক আছে কিনা অ্যাডমিন প্যানেল পরিষ্কার বা অগোছালো লাগবে তা নির্ধারণ করে

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

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

ডেভেলপাররা সাধারণত বিল্ডিং এবং ডিবাগিং লক্ষ্য করেই নাম রাখেন। অপারেটররা কাজ সহজে করতে নাম রাখেন। একজন ডেভেলপার acct, addr1 বা stat সহ্য করতে পারেন কারণ তিনি এর অর্থ মনে রাখেন। একজন অপারেটরকে ডিকোড না করেই “Account”, “Address line 1” এবং “Status” দেখতে হবে।

একটি অ্যাডমিন স্ক্রিনে “পঠনযোগ্য” সাধারণত মানে:

• আপনি একটি টেবিল স্ক্যান করে প্রতিটি কলাম খুলে না দিয়ে বুঝতে পারেন।
• আপনি সার্চ ও ফিল্টার করার সময় সেই একই শব্দগুলো ব্যবহার করতে পারেন যা দৈনন্দিন কাজে ব্যবহার করেন।
• আপনি সাজাতে ও তুলনা করতে পারেন without অপ্রত্যাশিততা (উদাহরণস্বরূপ, তারিখগুলো প্রকৃত তারিখ হিসেবে থাকে, স্ট্যাটাসগুলো ধারাবাহিক থাকে)।

যদি আপনি এমন একটি প্ল্যাটফর্ম ব্যবহার করেন যা মডেল থেকে স্ক্রিন জেনারেট করে (উদাহরণস্বরূপ, AppMaster-এর Data Designer এবং অ্যাডমিন-স্টাইল ভিউ), তাহলে নামগুলো UI ডিজাইনের একটি অংশ হয়ে যায়। ভালো নাম আপনাকে প্রথম দিন থেকেই পরিষ্কার ডিফল্ট স্ক্রিন দেবে, লেবেল ও লেআউট পালিশ করার আগে থেকেই।

একটি সহজ নামকরণ মৌলনীতি যা পুরো দল অনুসরণ করতে পারে

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

একটি আইডেন্টিফায়ার স্টাইল বেছে নিন এবং তা মিশ্রিত করবেন না। ডাটাবেসের জন্য, snake_case সাধারণত পড়া ও সার্চে সবচেয়ে সহজ। যদি আপনার স্ট্যাক camelCase প্রত্যাশা করে, পুরো জায়গায় (টেবিল, কলাম, ফরেন কী, এনাম) camelCase রাখুন। প্রকল্পের মাঝখেতে স্টাইল পরিবর্তন করলে লেবেল ও ফিল্টার এলোমেলো লাগতে শুরু করে।

অনেক দলের জন্য কার্যকর একটি মৌলনীতি:

• পুরো শব্দ ব্যবহার করুন: customer_id, নয় cust_id; description, নয় desc।
• জিনিসগুলোর জন্য পরিষ্কার নাম (নাউন) এবং অ্যাকশনের জন্য পরিষ্কার ক্রিয়া ব্যবহার করুন: invoice, payment, refund_requested।
• সামঞ্জস্যপূর্ণ টাইমস্ট্যাম্প নাম ব্যবহার করুন: created_at, updated_at, deleted_at।
• অস্পষ্ট শব্দ যেমন data, info, value, বা type থেকে বিরত থাকুন না হলে প্রসঙ্গ যোগ করুন (উদাহরণ: shipping_address, payout_method)।
• একবচন বনাম বহুবচন সঙ্গত রাখুন (অনেক দল টেবিল নাম বহুবচন ব্যবহার করে যেমন customers এবং কলাম singular যেমন customer_id)।

একটি ছোট গ্লসারি লিখে রাখুন এবং দৃশ্যমান রাখুন। প্রথমে সিদ্ধান্ত নিন আপনি customer, client, account, নাকি user বলতে কি বোঝাতে চান, এবং এক শব্দেই স্থির থাকুন। একইভাবে “order” বনাম “purchase” বা “ticket” বনাম “case”।

একটি দ্রুত চেক: যদি দুইজন একজন কলাম account_status দেখে প্রশ্ন না করেই অর্থ বুঝতে পারে, তাহলে মৌলনীতি কাজ করছে। না পারলে, স্ক্রিন ও ফিল্টার বানানোর আগে তাকে Rename করুন।

টেবিল নামকরণ নিয়ম যা মেনু ও তালিকার সঙ্গে পরিষ্কারভাবে মেলে

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

এন্টিটি টেবিলগুলির জন্য একটি স্টাইল বেছে নিন এবং সেটাই ব্যবহার করুন: singular (user, invoice, ticket) অথবা plural (users, invoices, tickets)। singular ফর্মটি ফর্ম শিরোনামের মধ্যে ভালো পড়ে (“Edit Ticket”), আর plural মেনুতে ভালো লাগতে পারে (“Tickets”)। দুইটি মিশালে নেভিগেশন অসংগত মনে হয়।

টেবিলকে তার কাজ না করে যা সেটা, সেই নামে রাখুন। একটি টেবিল এমন একটি জিনিস হওয়া উচিত যাকে আপনি নির্দেশ করতে পারেন। payment একটি জিনিস; processing একটি কাজ। পরে যদি আপনি রিফান্ড, রিট্রাই, সেটেলমেন্ট যোগ করেন, তাহলে “processing” টেবিল নাম বিভ্রান্তিকর হয়ে যাবে।

মেনু ও তালিকা পরিষ্কার রাখার নিয়ম:

• কংক্রিট নাম ব্যবহার করুন (customer, subscription, invoice, ticket_message)।
• স্থায়ী ডেটার জন্য বালতি-ধাঁচের টেবিল এড়িয়ে চলুন (settings, misc, temp, data)। এগুলোকে বাস্তব এন্টিটিতে ভাগ করুন (notification_setting, tax_rate, feature_flag)।
• সংক্ষিপ্ত, পাঠযোগ্য যৌগিক নাম অন্ডারস্কোর সহ ব্যবহার করুন (purchase_order, support_ticket)—সংকোচন নয়।
• মডিউল-প্রীফিক্স যোগ করুন কেবল তখনই যখন সংঘর্ষ রোধ করে (উদাহরণ: billing_invoice বনাম invoice)। যদি আপনি প্রিফিক্স করেন, পুরো মডিউলে সঙ্গতিপূর্ণভাবে করুন।

যদি আপনি AppMaster ব্যবহার করে সরাসরি স্ক্রিন জেনারেট করেন, তাহলে স্থির নাউন-ভিত্তিক টেবিল নাম সাধারণত ডিফল্ট মেনু ও লিস্ট ভিউ পরিষ্কার রাখে এবং পরে কম ক্লিনআপ লাগে।

জয়েন টেবিল ও আইডেন্টিফায়ার: many-to-many পরিষ্কার রাখা

Many-to-many সম্পর্ক এমন জায়গা যেখানে অ্যাডমিন প্যানেল প্রায়শই অগোছালো দেখায়। যদি জয়েন টেবিল ও তার কী-গুলো ভালো নামকরণ করা থাকে, জেনারেট করা স্ক্রিনগুলো ম্যানুয়াল ক্লিনআপ ছাড়া পড়তে সহজ থাকে।

একটি সোজা নিয়ম শুরু করুন এবং ভাঙবেন না: প্রতিটি টেবিলের একটি প্রাইমারি কী আছে যার নাম id। এক টেবিলে user_id প্রাইমারি কী এবং অন্যটিতে id ব্যবহার করা যাবে না। একরকম আইডেন্টিফায়ার সম্পর্ককে পূর্বানুমানযোগ্য করে তোলে এবং জেনারেটেড ফর্ম ও রেফারেন্স ফিল্ডগুলোকে সামঞ্জস্যপূর্ণ রাখে।

খাঁটি জয়েন টেবিলগুলির জন্য, দুটো এনটিটির নাম ব্যবহার করে এক ধাঁচ ও ক্রমে নাম দিন। সাধারণ অপশনগুলো হলো বর্ণানুক্রমিক (product_tag) অথবা “প্রধান জিনিস প্রথম” (user_role)। একটি ক্রম বেছে নিন এবং সর্বত্র সেটাই মেনে চলুন।

links বা mappings মতো অস্পষ্ট নাম এড়িয়ে চলুন, না হলে টেবিল সত্যিই জেনেরিক ক্রস-অবজেক্ট লিঙ্ক রাখলে তবেই ব্যবহার করুন। অধিকাংশ অ্যাডমিন প্যানেলে স্পেসিফিক নামই বুদ্ধিমানের চেয়ে ভালো।

কখন জয়েন টেবিল একটি বাস্তব এন্টিটি হয়

যদি সম্পর্কটির অতিরিক্ত ফিল্ড থাকে, তাহলে এটাকে নিজস্ব মডেল হিসেবে বিবেচনা করুন এবং এমন একটি নাম দিন যা মানুষ বুঝে: membership, assignment, subscription। উদাহরণস্বরূপ, যদি একটি user's role-এ থাকে starts_at, ends_at, এবং granted_by, user_role ঠিক আছে, কিন্তু UI-তে membership বেশি স্বাভাবিক পড়তে পারে।

একটি সহজ নিয়মের সেট যা স্ক্রিনগুলোকে প্রফেশনাল রাখে:

• প্রতিটি টেবিলেই প্রাইমারি কী হিসেবে id ব্যবহার করুন।
• জয়েন টেবিলগুলো নাম রাখুন উভয় এনটিটির নাম ব্যবহার করে এবং ক্রম ঠিক রাখুন (user_role)।
• পরিষ্কার ফরেন কী ব্যবহার করুন যেমন user_id এবং role_id।
• বাস্তব জীবনের মিল রাখার জন্য ইউনিকনেস নিয়ম যোগ করুন (উদাহরণ: প্রতিটি user_id-এ একটাই role_id)।
• যদি ইতিহাস অনুমতি দেন, ইউনিকনেস নিয়ম “active” রেকর্ডগুলোর সাথে মিলান করুন (উদাহরণ: যেখানে ended_at null)।

এসব সিদ্ধান্ত আপনার ডেটা বড় হওয়ার পরও কাজ করবে এবং AppMaster-এর Data Designer-এ ভালো ফল দেয়, যেখানে স্ক্রিন সরাসরি মডেল থেকে জেনারেট করা যায়।

ফিল্ড নামকরণ প্যাটার্নগুলি যা পরিষ্কার কলাম ও ফিল্টার দেয়

ফিল্ড নাম কেবল ডেভেলপারদের নয়—এগুলো ব্যবহারকারীরা কলাম হেডার, ফিল্টার লেবেল এবং ফর্ম ফিল্ড হিসেবে দেখে।

ভবিষ্যদ্বাণীযোগ্য সাফিক্সগুলো অনুমান দূর করে:

• ফরেন কী-র জন্য _id ব্যবহার করুন: customer_id, assigned_agent_id।
• টাইমস্ট্যাম্পের জন্য _at ব্যবহার করুন: created_at, paid_at, closed_at।
• কাউন্টারদের জন্য _count ব্যবহার করুন: login_count, attachment_count।

বুলিয়ানগুলো যেন সাধারণ বাক্য হিসাবে পড়েন। is_ এবং has_ ব্যবহার করুন যাতে চেকবক্সগুলো এক নজরে বোঝা যায়: is_active, has_paid, is_verified। is_not_approved মত ডাবল নেগেটিভ এড়িয়ে চলুন। যদি “না” স্টেট দরকার হয়, পজিটিভ মডেল করুন এবং কোডে লজিক ইনভার্ট করুন।

মানি ফিল্ডগুলো অ্যাডমিন গ্রিডে বিভ্রান্তির একটি সাধারণ উৎস। একটি পদ্ধতি বেছে নিন এবং সেটাই ব্যবহার করুন: ছোট ইউনিটে (পয়সা) সংখ্যারূপে স্টোর করুন, বা নির্দিষ্ট প্রিসিশনে দশমিক রাখুন। ফিল্ডটি এমনভাবে নামাবেন যাতে কেউ অনুমান না করে। উদাহরণ: total_amount_cents + currency_code, অথবা total_amount + currency_code। price, amount, total মিশ্রিত করবেন না যদি না তারা ভিন্ন ধরণের ধারণা বোঝায়।

টেক্সট ফিল্ডগুলো উদ্দেশ্য অনুযায়ী নির্দিষ্ট হওয়া উচিত, শুধু টাইপ নয়। description ব্যবহারকারী-দর্শনীয়; internal_comment ব্যক্তিগত; notes হল সাধারণ থলে এবং সাবধানে ব্যবহার করা উচিত। যদি আপনার একাধিক নোট থাকে, শ্রোতা অনুযায়ী নাম দিন: customer_note, agent_note।

কন্টাক্ট ফিল্ডগুলো সরাসরি রাখুন কারণ সেগুলো দ্রুত ফিল্টারের জন্য কাজে লাগে: website_url, contact_email, billing_email। AppMaster-এ জেনারেটেড অ্যাডমিন স্ক্রীনে এই ধরনের নামগুলো সাধারণত পরিষ্কার ডিফল্ট লেবেলে পরিণত হয়।

রিলেশন ও ফরেন কী: ডাটা মডেল ব্যাখ্যা করে এমন নাম

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

একটি নিয়ম রাখুন: ফরেন কী কলামটি রেফারেন্স করা টেবিলের নামের সাথে _id যোগ করলে হবে। যদি আপনার কাছে customer.id থাকে, ব্যবহার করুন customer_id। যদি order.id থাকে, ব্যবহার করুন order_id। এই সঙ্গতি কলামটি কোথায় নির্দেশ করছে তা স্পষ্ট করে।

সেলফ-রিলেশনগুলো অতিরিক্ত স্পষ্টতা চায় কারণ পরে সহজে ভুল পড়া যায়। related_id-এর মতো জেনেরিক নাম এড়িয়ে চলুন। দিক ও অর্থ বোঝাতে এমন নাম ব্যবহার করুন, যেমন গাছ-স্ট্রাকচারের জন্য parent_id, সংস্থার চার্টের জন্য manager_id, বা ডেডুপিং-র জন্য merged_into_id।

যখন একটি রিলেশন জয়েন টেবিল জড়িত করে, তখন নামগুলো বাক্যর মতো পড়ার উপযোগী রাখুন। উদাহরণ: যদি ভূমিকা হয় “assignee”, তাহলে ticket_assignee.user_id ticket_user.user_id থেকে বেশি পরিষ্কার।

প্রায়োগিক চেকগুলো যা বেশিরভাগ সমস্যা রোধ করে:

• একই নামে owner_id বিভিন্ন অর্থে পুনরায় ব্যবহার করবেন না। created_by_user_id, account_manager_user_id, বা billing_contact_id-এর মতো স্পষ্ট নাম ব্যবহার করুন।
• একই টেবিলে একাধিক রিলেশন থাকলে ভূমিকা অন্তর্ভুক্ত করুন: requested_by_user_id এবং approved_by_user_id।
• একটিই soft delete মার্কার বেছে নিন এবং সেটাই ব্যবহার করুন। deleted_at ব্যাপকভাবে বোঝাপড়া যায় এবং ফিল্টারের সঙ্গে কাজ করে।

যদি আপনি পরে AppMaster-এ স্ক্রিন বানান, এই নামগুলো সর্বত্র দেখাবে, তাই একটু যত্ন আপনাকে অনেক UI ক্লিনআপ বাঁচায়।

এনাম ও স্ট্যাটাস ফিল্ড যা সময়ের সাথে বোঝার যোগ্য থাকে

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

একটি ব্যবহারযোগ্য নিয়ম: যদি ব্যবহারকারীরা জিজ্ঞেস করবে “এই আইটেম তার যাত্রায় কোথায় আছে?”, সেটা হলো স্ট্যাটাস। যদি প্রশ্ন হয় “এটাকে লুকাতে হবে কি?” বা “এটা লক করা আছে কি?”, তা আলাদা বুলিয়ান হওয়া উচিত।

এক স্ট্যাটাস পাঁচটি বুলিয়ান-এর চেয়ে ভাল

is_new, is_in_progress, is_done, is_cancelled ইত্যাদির বদলে একটি ticket_status ব্যবহার করুন। এটি তালিকা কলাম, ফিল্টার এবং বাল্ক অ্যাকশনে ভালো পড়ে। একই সাথে অসম্ভব সংমিশ্রণ যেমন “done + in_progress” এড়ানো যায়।

এনাম মানগুলো স্থিতিশীল রাখুন। UI টেক্সট বদলানো যেতে পারে, কিন্তু সঞ্চিত মান বদলানো ঠিক না। pending স্টোর করুন, waiting_for_review নয়। rejected স্টোর করুন, rejected_by_manager নয়। পরবর্তী সময়ে আপনি সহজে বন্ধুত্বপূর্ণ লেবেল দেখাতে পারেন ডাটা মাইগ্রেশন ছাড়া।

যখন অতিরিক্ত বিশদ প্রয়োজন, স্ট্যাটাস ওভারলোড করবেন না—একটি আলাদা ফিল্ড যোগ করুন। উদাহরণ: payment_status কে লাইফসাইকেল রাখুন, এবং প্রয়োজনে failure_reason (টেক্সট) যোগ করুন।

এনাম নামকরণ ডোমেইন অনুসারে করুন (ফিল্টারগুলো যাতে অর্থ রাখে)

একাধিক মডেলে “status” থাকলে স্ক্রিনগুলো যেন পড়তে সহজ থাকে সেই জন্য ডোমেইন প্রিফিক্স ব্যবহার করুন:

• payment_status (অর্ডার চেকআউট)
• ticket_priority (সাপোর্ট জরুরিতা)
• user_role (অ্যাক্সেস লেভেল)
• invoice_status (বিলিং লাইফসাইকেল)
• delivery_status (শিপিং লাইফসাইকেল)

লাইফসাইকেল আলাদা রাখুন অপারেশনাল ফ্ল্যাগ থেকে। উদাহরণ: status workflow-এ কোথায় আছে দেখায়, আর is_archived মানে এটি দৈনন্দিন তালিকা থেকে লুকানো হওয়া উচিত।

প্রতিটি এনাম ভ্যালুর জন্য এক-লাইনের অর্থ টিম নোটে লিখে রাখুন। ভবিষ্যৎ আপনি প্রায়ই cancelled এবং voided এর মধ্যে পার্থক্য ভুলে যাবেন। যদি আপনি AppMaster ব্যবহার করেন, সেই সংক্ষিপ্ত সংজ্ঞাগুলোও জেনারেটেড ড্রপডাউন ও ফিল্টারগুলোকে কনসিস্টেন্ট রাখে ওয়েব ও মোবাইল উভয়ই।

এজ কেস: তারিখ, অডিট ফিল্ড, এবং “type” কলাম

নামকরণ গাইডগুলো সাধারণত টেবিল ও বেসিক ফিল্ড কভার করে, কিন্তু অ্যাডমিন প্যানেলগুলো এজ কেসে অগোছালো হয়। তারিখ, অডিট ফিল্ড, এবং type কলামগুলোই সেখানে বিভ্রান্তি তৈরি করে।

তারিখ ও টাইমস্ট্যাম্পের জন্য নামটি কাহিনী বলুক: এটা কি পরিকল্পিত, প্রকৃত, না একটি রিমাইন্ডার? একটি সহজ প্যাটার্ন হলো ক্রিয়াপদ-মর্মক অর্থ যোগ করা এবং স্পষ্ট সাফিক্স ব্যবহার করা। উদাহরণ: due_at (পরিকল্পিত ডেডলাইন) এবং completed_at (প্রকৃত সমাপ্তি) — এগুলো পড়ে বোঝা যায়। start_date ও end_date মতো অস্পষ্ট জোড়া নাম থেকে বিরত থাকুন যদি আপনি প্রকৃতই scheduled_at এবং finished_at বোঝাতে চান।

ঐচ্ছিক রিলেশন আরেকটি ফাঁদ। প্রতিটি টেবিলে নতুন প্যাটার্ন আবিষ্কার করবেন না। রিলেশন নাম স্থির রাখুন এবং null-কে অর্থ করতে দিন। manager_id যদি ঐচ্ছিকও হয়, তবু নাম থাকুক manager_id।

ঠিকানাগুলো কোডে ঠিক থাকলেও গ্রিডে কুঁজে লাগতে পারে। নম্বর-কৃত লাইনগুলো ঠিক আছে যদি আপনার দল সর্বত্র এর মানে সম্মত হয়। সেগুলো স্পষ্ট রাখুন:

• address_line1, address_line2, city, region, postal_code, country_code
• address1, address2 এড়িয়ে চলুন (পড়তে কঠিন ও ডুপ্লিকেটের ঝুঁকি বেশি)

অডিট ফিল্ডগুলো ইচ্ছাকৃতভাবে বিরক্তিকর হওয়া উচিত:

• created_at, updated_at
• created_by_id, updated_by_id (শুধু যদি আপনি প্রকৃতই ইউজার ট্র্যাক করতে চান)

type নিয়ে সাবধানে থাকুন। এটি প্রায়শই খুব বিস্তীর্ণ এবং সময়ের সাথে ধীরেধীরে গোলমেলে হয়ে পড়ে। type এর বদলে অর্থ অনুযায়ী নাম রাখুন: payment_method, ticket_channel, customer_tier। স্কিমা-চালিত অ্যাডমিন স্ক্রিনে (তাতে AppMaster অন্তর্ভুক্ত) একটিই পছন্দ পরিষ্কার ফিল্টার বনাম বিভ্রান্তি তৈরি করে।

উদাহরণ: এমন একটি সাপোর্ট টিকেট মডেল নামকরণ যা অ্যাডমিনে ভালো দেখায়

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

সাইডবারে মন্তব্যের মতো পড়ে এমন টেবিল নাম দিয়ে শুরু করুন:

• customer
• ticket
• ticket_message
• ticket_tag
• ticket_tag_link

অধিকাংশ অ্যাডমিন প্যানেলে এগুলো “Tickets” ও “Ticket Messages” মতো লেবেলে পরিণত হয়, এবং জয়েন টেবিল সাধারণত ঝামেলা করে না।

টিকেট তালিকা স্ক্রিনের জন্য এমন ফিল্ড নাম বেছে নিন যা পরিষ্কার কলাম হেডার ও ফিল্টার তৈরি করে:

• subject, status, priority
• assigned_to_id (স্টাফ ইউজারকে নির্দেশ করে)
• last_message_at (সর্বশেষ অনুযায়ী সাজাতে ব্যবহৃত)
• created_at (স্ট্যান্ডার্ড ও পূর্বানুমানযোগ্য)

এনাম হলো যেখানে পড়তে সহজতা পরে নষ্ট হয়ে যেতে পারে, তাই সেটগুলো স্থির ও সাধারণ রাখুন:

• ticket_status: new, open, pending_customer, resolved, closed
• ticket_priority: low, normal, high, urgent

একটি নামকরণ সিদ্ধান্ত যা ঘন ঘন বিভ্রান্তি প্রতিরোধ করে: “customer” ওভারলোড করবেন না। সাপোর্টে অনুরোধকারী সব সময় গ্রাহক নাও হতে পারে (কেউ সহকর্মীর পক্ষ থেকে জমা দিতে পারে)। যদি আপনি জমা দেয়ার ব্যক্তিকে সংরক্ষণ করেন, তাকে নাম দিন requester_id, আর আলাদা করে রাখুন customer_id সেই অ্যাকাউন্টটির জন্য যার সম্পর্কে টিকেট। এই ভেদাভেদ ফর্ম ও ফিল্টারকে প্রথম দিন থেকেই সৎ রাখে।

ধাপে ধাপে: স্ক্রিন বানানোর আগে কিভাবে একটি নতুন মডেল নামকরণ করবেন

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

প্রতিটি ফিচারের জন্য পুনরাবৃত্তিযোগ্য প্রক্রিয়া

1. একটি ছোট গ্লসারি (৫–১০ টার্ম) দিয়ে শুরু করুন। এমন শব্দগুলো লিখুন যেগুলো একটি নন-টেকনিক্যাল সঙ্গী মিটিংয়ে ব্যবহার করবে, তারপর প্রতিটি ধারণার জন্য একটি পছন্দের শব্দ বেছে নিন (উদাহরণ: “customer” বনাম “client”)।

2. আপনি যে স্ক্রিনগুলো প্রত্যাশা করেন সেগুলো স্কেচ করুন: list, detail, create, edit। তালিকা ভিউয়ের জন্য ঠিক করুন কোন ৫–৮টি কলাম তৎক্ষণাত স্পষ্ট হতে হবে। যদি একটি ফিল্ড নাম হেডারের মতো মূর্তি করে, সম্ভবত সেটি কাজ করবে না।

3. টেবিল ও রিলেশন খসড়া করুন, তারপর সাফিক্স নিয়ম ব্যবহার করে ফিল্ড নাম দিন (*_id, *_at, is_*, *_count)। পরে যখন আপনি অ্যাডমিন স্ক্রিন জেনারেট করবেন (AppMaster-এ সহ), এই প্যাটার্নগুলো সাধারণত পরিষ্কার লেবেল ও পূর্বানুমানযোগ্য ফিল্টার দেয়।

চলবার আগে নিশ্চিত করুন আপনি স্টাইল মিশাচ্ছেন না (customer_id একটি টেবিলে, clientId অন্যটিতে)। সঙ্গতিটি বুদ্ধিমত্তার চেয়ে কাজের।

4. এনামগুলো আগে থেকেই সংজ্ঞায়িত করুন, না যে প্রথম UI তৈরি হওয়ার পরে। প্রতিটি মানের জন্য এক-লাইনের ব্যাখ্যা লিখুন, যেন আপনি সাপোর্ট স্টাফকে বোঝাচ্ছেন। টেকসই মান যেমন pending, active, archived পছন্দ করুন — না যে new, newer, newest।

5. একটি “কলাম হেডার রিড-থ্রু” করুন। ভাবুন আপনি অ্যাডমিন ব্যবহারকারী এবং একটি টেবিল স্ক্যান করছেন:

• “Created At”, “Updated At”, “Status”, “Assigned To”, “Total Amount” কি অনুমতি ছাড়া বোঝা যাবে?
• কোনো ফিল্ড যেন অভ্যন্তরীণ কোডের মতো শোনায় (tmp_flag, x_type, data1)?
• ইউনিটগুলো কি স্পষ্ট (amount_cents বনাম amount, duration_seconds বনাম duration)?

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

সাধারণ নামকরণ ভুলগুলো যা অ্যাডমিন প্যানেল ব্যবহারে কষ্ট দেয়

যদি স্কিমা বিশৃঙ্খল হয়, স্ক্রিনগুলোও বিশৃঙ্খল দেখাবে—ইউআই যত ভালোই হোক না কেন। নামকরণ কনভেনশনগুলো “স্টাইল” এর চেয়ে দৈনন্দিন ব্যবহারযোগ্যতার ব্যাপার।

প্রথম ফাঁদ হলো মিশ্রিত শব্দভান্ডার। এক টেবিলে client আর অন্যটিতে customer থাকলে আপনার মেনু, ফিল্টার, এবং সার্চ ফলাফল ভিন্ন বস্তু বর্ণনা করছে বলে মনে হবে। প্রতিটি মূল ধারণার জন্য একটি শব্দ বেছে নিন এবং সারা সিস্টেমে ব্যবহার করুন, রিলেশন নামেও।

আরেকটি সাধারণ সমস্যা অতিরিক্ত সংক্ষিপ্ত করা। addr, misc, বা info রকম সংক্ষিপ্তকরণ কয়েক অক্ষর বাঁচায় কিন্তু টেবিল ও এক্সপোর্টে স্পষ্টতা নষ্ট করে।

তৃতীয় ভুল UI ফ্লো ডাটাবেসে এমবেড করা। new_customer_wizard_step মত একটি ফিল্ড লঞ্চের সময় অর্থপূর্ণ হতে পারে, কিন্তু যখন ফ্লো বদলায় বা দ্বিতীয় অনবোর্ডিং পাথ যোগ করেন, তা বিভ্রান্তিকর হয়ে পড়ে। ব্যবসায়িক তথ্য সংরক্ষণ করুন (উদাহরণ: onboarding_status) এবং UI কিভাবে গাইড করবে তা UI-তে নির্ধারণ করুন।

বুলিয়ান ওভারলোড সম্পর্কে সতর্ক থাকুন। যখন আপনি is_new, is_open, এবং is_closed যোগ করবেন, শেষপর্যন্ত দ্বন্দ্ব (একসাথে দুটি true) এবং অস্পষ্ট ফিল্টার পাবেন। প্রধান লাইফসাইকেলের জন্য একটিই স্ট্যাটাস ফিল্ড ব্যবহার করুন।

রেড ফ্ল্যাগ যা সাধারণত কটু অ্যাডমিন স্ক্রিন দেয়:

• একই জিনিসের জন্য দুইটা নাম (client_id এক জায়গায়, customer_id অন্য জায়গায়)
• ক্যাচ-অল কলাম (notes, misc, extra) যেখানে মিশ্র ডেটা জমে
• টাইম-নির্ভর নাম (summer_campaign_*) যা ক্যাম্পেইনের পরে অবচেতন হয়ে যায়
• একাধিক বুলিয়ান যা এক অবস্থা বোঝাতে চায়
• রিনেমগুলো ছুদা করে করা, মাইিগ্রেশন প্ল্যান ছাড়া

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

চালানের আগে দ্রুত চেকলিস্ট

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

• টেবিলগুলো বাস্তবে কি বোঝায় তা শোনা যায় কি? একটি সহকর্মী টেবিলটি কি উপস্থাপন করে বলে বলতে পারবে (ticket, customer, invoice)?
• কী ফিল্ডগুলো পূর্বানুমানযোগ্য সাফিক্স অনুসরণ করে? মানুষ যা এক ঝলকেই চিনবে সেই প্যাটার্ন: *_id রেফারেন্সের জন্য, *_at টাইমস্ট্যাম্পের জন্য, *_amount (বা *_amount_cents) অর্থের জন্য, এবং is_* সত্য/মিথ্যার জন্য।
• এনামগুলো স্থিতিশীল ও সাধারণ কি? UI বাক্যাংশের পরিবর্তে pending, paid, failed মত মান সংরক্ষণ করা হচ্ছে কি?
• একটি নতুন সহকর্মী অর্থ অনুমান করে নিতে পারবে? যদি ফিল্ডগুলো কোনো হেল্পটেক্সট ছাড়া জেনারেটেড লিস্ট ভিউতে দেখানো হয়, তখনও উদ্দেশ্য কি পরিষ্কার থাকবে?
• অস্পষ্ট শব্দগুলো সরানো বা নির্দিষ্ট করা হয়েছে কি? data, value, type, বা info রকম জাঙ্ক-ড্রয়ার নামগুলো status, source, category, notes, বা external_reference সহ প্রতিস্থাপন করা হয়েছে কি?

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

পরবর্তী পদক্ষেপ: নামকরণকে অভ্যাস বানান (এবং স্ক্রিনগুলিকে একরকম রাখুন)

ভালো নামকরণ একবারের কাজ নয়—এটি একটি ছোট রুটিন যা আপনার অ্যাডমিন UI পড়তে সুবিধাজনক রাখে যত/schema বড় হয়।

একটি বিদ্যমান মডিউল দিয়ে শুরু করুন এবং নিয়মগুলো শুধুমাত্র পরের নতুন টেবিলে প্রয়োগ করুন। এতে ভয়ঙ্কর রিফ্যাক্টর এড়ানো যায় এবং বাস্তবে কাজ করার জন্য একটি জায়গা থাকে অনুশীলন করার। যদি আপনার পরবর্তী ফিচার অর্ডারে “returns” যোগ করে, টেবিল, ফরেন কী, এবং স্ট্যাটাসগুলো আপনার প্যাটার্ন অনুযায়ী নাম দিন day-one-এ, তারপর পরের ফিচারে একই পদ্ধতি পুনরায় ব্যবহার করুন।

স্কিমা কাজের পাশে একটি এক-পৃষ্ঠার নামকরণ গাইড রাখুন। ছোট রাখুন: টেবিল কিভাবে নামকরণ করবেন, প্রাইমারি কী, ফরেন কী, টাইমস্ট্যাম্প, এবং স্ট্যাটাস এনাম। লক্ষ্য দ্রুত সিদ্ধান্ত নেওয়া, লম্বা বিতর্ক নয়।

আপনি যদি AppMaster-এ বিল্ড করেন, তাহলে Data Designer-এ এই প্যাটার্নগুলো ঠিক করে রাখা সাহায্য করে UI স্ক্রিনে হাত ছাড়া চালু করার আগে। যখন আপনি টেবিল বা ফিল্ডের নাম বদলান, অ্যাপ পুনরায় জেনারেট করুন যাতে স্ক্রিন, API, এবং লজিক সমন্বিত থাকে এবং বিচ্ছিন্ন না হয়।

প্রতি রিলিজের আগে একটি হালকা রিভিউ ধাপ সাধারণত যথেষ্ট:

• টেবিল ও ফিল্ড নামগুলো মেনু আইটেম, কলাম হেডার, ও ফিল্টার হিসেবে পড়লে কি মানে বোঝায়?
• স্ট্যাটাস ও এনামগুলো অতিরিক্ত ব্যাখ্যা ছাড়া পরিষ্কার কি?
• রিলেশন ও ফরেন কী নিজেই বোঝাচ্ছে কি (রহস্যময় সংক্ষিপ্তকরণ নেই)?
• একই ধরনের মডেলগুলো সঙ্গত কি (একই শব্দ, একই ক্রম)?

সময় গেলে প্রকৃত জয় হলো সঙ্গতি। যখন প্রতিটি নতুন মডেল একই নিয়ম অনুসরণ করে, আপনার জেনারেটেড অ্যাডমিন প্যানেলগুলো ডিজাইনকৃত মনে হওয়া শুরু করবে কারণ লেবেল ও তালিকাগুলো একসঙ্গে coherent পণ্য হিসেবে পড়ে — এমনকি যখন সেগুলো জেনারেট করা হয়।