নো-কোড অ্যাপগুলিতে ফর্ম ভ্যালিডেশনের জন্য ডাটাবেস কনস্ট্রেইন্ট

কেন খারাপ ফর্ম ডেটা দ্রুত ছড়ায়

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

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

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

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

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

একটি অভ্যন্তরীণ অর্ডার ফর্ম কল্পনা করুন যা কোনো নো-কোড টুলে তৈরি—উদাহরণস্বরূপ AppMaster। যদি একটি অর্ডার মিসিং কাস্টমার লিংক বা ডুপ্লিকেট অর্ডার নম্বর সহ সেভ হয়, তা ইনভয়েস, শিপিং টাস্ক এবং রাজস্ব রিপোর্টে বিষাক্ত প্রভাব ফেলতে পারে। সাবমিট করার সময় ধরলে ডাউনস্ট্রিম সবকিছু পরিষ্কার থাকে এবং পরে কষ্টসাধ্য ক্লিনআপ বাঁচে।

ডাটাবেস কনস্ট্রেইন্ট — জার্গন ছাড়া ব্যাখ্যা

ডাটাবেস কনস্ট্রেইন্টগুলো হলো ডাটাবেসে থাকা সরল নিয়ম। এগুলো প্রতিবার ডেটা সেভ করার সময় চালান, যেখান থেকেই যাতে না আসে: ওয়েব ফর্ম, মোবাইল স্ক্রিন, ইম্পোর্ট বা API কল। যদি কোনো নিয়ম ভঙ্গ হয়, ডাটাবেস সেভটি প্রত্যাখ্যান করে।

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

যখন মানুষ ডাটাবেস কনস্ট্রেইন্ট নিয়ে ফর্ম ভ্যালিডেশন সম্পর্কে কথা বলে, তারা বলতে চায়: ডাটাবেসকে চূড়ান্ত বিচারক হতে দিন, এবং UI-কে ব্যবহারকারীকে এমনভাবে গাইড করতে দিন যাতে তারা খুব কমই সেই দেয়ালের মুখোমুখি হয়।

বেশিরভাগ বাস্তব অ্যাপ তিনটি বেসিক দিয়ে অনেক কভার করে:

• Unique: “এই মানটি একটাই হতে হবে।” উদাহরণ: ইমেইল, এমপ্লয়ি আইডি, ইনভয়েস নম্বর।
• Check: “এই শর্তটি সত্য হতে হবে।” উদাহরণ: quantity > 0, start_date <= end_date।
• Foreign key: “এইটি অন্য টেবিলের একটি বাস্তব রেকর্ডকে ইঙ্গিত করবে।” উদাহরণ: প্রতিটি অর্ডারকে একটি বিদ্যমান কাস্টমারের সাথে জুড়তে হবে।

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

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

কনস্ট্রেইন্ট থেকে স্পষ্ট, মানবীয় ত্রুটি বার্তা পর্যন্ত

কনস্ট্রেইন্ট খারাপ ডেটা আটকাতে চমৎকার, কিন্তু কাঁচা ডাটাবেস ত্রুটিগুলো সাধারণত ডেভেলপারদের জন্য লেখা—ফর্ম পূরণকারী মানুষের জন্য নয়। লক্ষ্যটি সহজ: নিয়ম ডাটাবেসে রাখুন, তারপর ব্যর্থতাকে এমন একটি বার্তায় অনুবাদ করুন যা কি হয়েছে এবং পরবর্তী কী করা যাবে তা বোঝায়।

প্রতিটি কনস্ট্রেইন্টকে একটি ছোট “ত্রুটি চুক্তি” হিসেবে বিবেচনা করুন যার দুইটি অংশ: কি ভুল হয়ে গেছে, এবং কিভাবে ঠিক করা যাবে। আপনার UI বন্ধুভাবে থাকবে কিন্তু ডেটা নিয়ম দুর্বল হবে না।

কয়েকটি অনুবাদ যেগুলো ভালো কাজ করে:

• খারাপ: “Unique constraint violation on users_email_key”

• ভাল: “এই ইমেইলটি ইতিমধ্যেই ব্যবহৃত হচ্ছে। সাইন ইন করুন অথবা অন্য ইমেইল ব্যবহার করুন।”

• খারাপ: “Check constraint failed: order_total_positive”

• ভাল: “টোটাল 0 থেকে বড় হতে হবে। অন্তত একটি আইটেম যোগ করুন বা পরিমাণ পরিবর্তন করুন।”

• খারাপ: “Foreign key violation on customer_id”

• ভাল: “একটি বৈধ কাস্টমার নির্বাচন করুন। যদি তারা নতুন হন, 먼저 কাস্টমার তৈরি করুন।”

কোথায় বার্তাগুলো দেখাবেন সেটাও শব্দগুলোর মতোই গুরুত্বপূর্ণ। এক-ফিল্ড ত্রুটিকে ফিল্ডের পাশে দেখান। ক্রস-ফিল্ড নিয়মের জন্য (যেমন “end date অবশ্যই start date-র পরে হতে হবে”) ফর্ম-লেভেলের ব্যানার স্পষ্ট হতে পারে।

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

ওয়েব ও মোবাইল উভয়ে শব্দচয়ন ধারাবাহিক রাখুন। যদি ওয়েব ফর্ম বলে “একটি বৈধ কাস্টমার নির্বাচন করুন,” আপনার মোবাইল অ্যাপ যেন “Invalid FK” না বলে। একই সংক্ষিপ্ত ক্রিয়াপদের (“Select/Choose,” “Enter,” “Remove”) ব্যবহার করুন যাতে ব্যবহারকারীরা কি আশা করবেন সেটি শিখে নেয়।

আপনি যদি AppMaster-এ নির্মাণ করে থাকেন, এই ম্যাপিং ইচ্ছাকৃতভাবে ডিজাইন করার বিষয়: ডাটাবেস কঠোর থাকবে, আর UI লজিক ব্যর্থতাগুলোকে শান্ত, নির্দিষ্ট নির্দেশে পরিণত করবে।

ধাপে ধাপে: প্রথমে নিয়ম তৈরি করুন, তারপর ফর্ম

যদি আপনি প্রথমে ফর্ম ডিজাইন করেন, আপনি কাইরে রেইস কেসগুলোর পিছনে ছুটবেন। যদি প্রথমে ডাটা নিয়ম ডিফাইন করেন, UI সহজ হয় কারণ এটি ডাটাবেসে ইতিমধ্যেই থাকা নিয়মগুলোকে প্রতিফলিত করে।

একটি ব্যবহারিক বিল্ড অর্ডার:

1. কয়েকটা আসল গুরুত্বপূর্ণ ফিল্ড লিখে রাখুন। সরল ভাষায় “বৈধ” কী তা সংজ্ঞায়িত করুন। উদাহরণ: “ইমেইল ইউনিক হতে হবে,” “পরিমাণ 1 বা ততোধিক হতে হবে,” “প্রতিটি অর্ডারকে অবশ্যই একটি কাস্টমারের মধ্যে থাকতে হবে।”
2. টেবিল এবং রিলেশনশিপগুলো মডেল করুন। স্ক্রিন আঁকার আগে সিদ্ধান্ত নিন কি কোথায় যাবে।
3. অপরিবর্তনীয় নিয়মগুলোর জন্য কনস্ট্রেইন্ট যোগ করুন। ডুপ্লিকেটের জন্য unique, সবসময়-সত্য রুলের জন্য check, এবং রিলেশনের জন্য foreign keys ব্যবহার করুন।
4. কনস্ট্রেইন্ট মেলে এমন UI বানান। রিকুইার্ড ফিল্ড চিহ্নিত করুন, সঠিক ইনপুট টাইপ ব্যবহার করুন, এবং সরল হিন্ট যোগ করুন। UI ব্যবহারকারীদের গাইড করবে, কিন্তু ডাটাবেস চূড়ান্ত গেট থাকবে।
5. সাংকেতিকভাবে ভাঙে দেখুন। মেসি মান পেস্ট করুন, ডুপ্লিকেট চেষ্টা করুন, এবং মিসিং সম্পর্কিত রেকর্ড সিলেক্ট করার চেষ্টা করুন। তারপর লেবেল ও ত্রুটি টেক্সট উন্নত করুন যতক্ষণ না ঠিক কি ঠিক করতে হবে তা স্পষ্ট হয়।

দ্রুত উদাহরণ

ধরা যাক আপনি একটি অভ্যন্তরীণ “New Order” ফর্ম নির্মাণ করছেন। আপনি ব্যবহারকারীকে কাস্টমার নাম দিয়ে সার্চ করতে দিতে পারেন, কিন্তু ডাটাবেস কেবল একটি সত্যিকারের Customer ID গ্রহণ করবে (foreign key)। UI-তে এটি একটি সার্চেবল পিকার হয়ে যাবে। ব্যবহারকারী যদি কাস্টমার না বেছে নিয়ে সাবমিট করে, মেসেজ সহজে বলবে “একটি কাস্টমার নির্বাচন করুন” বদলে পরে বিভ্রান্ত সেভ ত্রুটিতে পড়ার চেয়ে।

এটি ওয়েব ও মোবাইল ফর্মগুলোর মধ্যেকার নিয়মগুলো পুনরাবৃত্তি না করে কনসিস্টেন্ট রাখে।

এমন ইউনিক কনস্ট্রেইন্ট যা মানুষই সাধারণত সৃষ্টি করে এমন ডুপ্লিকেট থামে

Unique কনস্ট্রেইন্ট সবচেয়ে সহজ উপায় ডুপ্লিকেট জমাট হওয়ার প্রতি বাধা দেয়। ফর্ম যদি মিস করেও ডুপ্লিকেট ইনপুট করে, ডাটাবেস সেটাকে প্রত্যাখ্যান করবে।

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

প্রথম সিদ্ধান্ত হলো স্কোপ। কিছু মান সিস্টেম জুড়ে ইউনিক হতে হবে (উদাহরণ: ইউজারনেম)। অন্যগুলো শুধুমাত্র একটি প্যারেন্ট গ্রুপের ভেতরে ইউনিক দরকার (একটি প্রতিষ্ঠানভিত্তিক ইনভয়েস নম্বর বা গুদামের ভেতরে এসেট ট্যাগ)। স্কোপ সচেতনভাবে বেছে নিন যাতে বৈধ ডেটা ব্লক না হয়।

চিন্তা করার একটি ব্যবহারিক উপায়:

• Global unique: পুরো সিস্টেমে এক মান, এক রেকর্ড (username, public handle)
• Per-organization unique: কোম্পানি/টিম স্তরে ইউনিক (invoice_number + org_id)
• Per-location unique: সাইট স্তরে ইউনিক (asset_tag + location_id)

কনফ্লিক্ট হ্যান্ডল করা নিয়মের মতোই গুরুত্বপূর্ণ। যখন unique কনস্ট্রেইন্ট ফেল করে, শুধু “ইতিমধ্যে আছে” বলবেন না। বলুন কি কনফ্লিক্ট করেছে এবং ব্যবহারকারী পরবর্তী কি করতে পারে। উদাহরণ: “Invoice number 1047 ইতিমধ্যেই Acme Co.-এর জন্য আছে। 1047-2 চেষ্টা করুন, অথবা বিদ্যমান ইনভয়েসটি খুলুন।” যদি UI নিরাপদে বিদ্যমান রেকর্ডটি রেফার করতে পারে, তখন তৈরি তারিখ বা মালিকের ছোট একটা হিন্ট ব্যবহারকারীকে উদ্ধার করতে সাহায্য করবে বিনা সংবেদনশীল তথ্য প্রকাশ করে।

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

AppMaster-এ unique নিয়ম প্রথমে Data Designer-এ নির্ধারণ করুন, তারপর ফর্মে বন্ধুত্বপূর্ণ মেসেজ মিরর করুন। ডাটাবেস চূড়ান্ত গেটকিপার থাকবে, এবং UI সৎ থাকবে কারণ এটি একটি বাস্তব নিয়ম ব্যাখ্যা করছে।

চেক কনস্ট্রেইন্ট — সবসময় সত্য থাকা উচিত এমন নিয়মের জন্য

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

সেরা চেকগুলো সরল এবং পূর্বানুমানযোগ্য। যদি একজন ব্যবহারকারী রুল অনুমান করতে না পারে, তারা বারবার ত্রুটিতে পড়বে এবং ফর্মকে দোষ দেবে। চেকগুলো ঘটনাবলীভিত্তিক রাখুন, জটিল নীতি নয়।

দ্রুত ফল পাওয়া যায় এমন সাধারণ চেক কনস্ট্রেইন্টগুলো:

• রেঞ্জ: quantity between 1 and 1000, age between 13 and 120
• অনুমোদিত স্টেট: status Draft, Submitted, Approved, বা Rejected হতে হবে
• পজিটিভ নাম্বার: amount > 0, discount between 0 and 100
• তারিখ ক্রম: end_date >= start_date
• সরল লজিক: যদি status = Approved হয় তবে approved_at null নয়

চেকগুলোকে বন্ধুত্বপূর্ণ মনে করার ট্রিক হচ্ছে UI মেসেজ কিভাবে বর্ণনা করা হয়েছে। কনস্ট্রেইন্ট নামটি কপি করে বলবেন না। ব্যবহারকারীকে কি পরিবর্তন করতে হবে তা বলুন।

ভালো প্যাটার্ন:

• “Quantity অবশ্যই 1 এবং 1000 এর মধ্যে হতে হবে।”
• “একটি স্ট্যাটাস নির্বাচন করুন: Draft, Submitted, Approved, বা Rejected।”
• “End date অবশ্যই start date-এর সমান অথবা পরে হতে হবে।”
• “Amount অবশ্যই 0-এর চেয়ে বড় হতে হবে।”

নো-কোড নির্মাণ করলেও (যেমন AppMaster UI-কম্পোনেন্ট মডেলগুলোর সাথে বাইন্ড করে) ফর্মে একই চেকগুলো মিরর করা ঠিক আছে যাতে ইনস্ট্যান্ট ফিডব্যাক পাওয়া যায়, কিন্তু ডাটাবেস চেক কনস্ট্রেইন্টকে চূড়ান্ত গার্ডরেইল হিসাবে রাখুন। ফলে ভবিষ্যতে কোনো নতুন স্ক্রিন যোগ করলে নিয়ম এখনও বজায় থাকবে।

ফরেন কি — রিলেশনগুলো বাস্তব রাখে

Foreign key (FK) একটি সরল প্রতিশ্রুতি জার: যদি কোনো ফিল্ড বলে এটি অন্য রেকর্ডকে নির্দেশ করে, সেই অন্য রেকর্ডটি অবশ্যই থাকা চাই। যদি একটি Order-এ CustomerId থাকে, ডাটাবেস এমন কোনো অর্ডার প্রত্যাখ্যান করবে যা এমন কোনো কাস্টমারের দিকে নির্দেশ করে না যেটি Customers টেবিলে আছে।

এটি গুরুত্বপূর্ণ কারণ রিলেশনশিপ ফিল্ডগুলো হচ্ছে যেখানে “প্রায় ঠিক” ডেটা দেখা যায়। কেউ কাস্টমারের নাম একটু ভূল লিখতে পারে, পুরনো ID পেস্ট করতে পারে, বা এমন রেকর্ড সিলেক্ট করতে পারে যা вчера মোছা হয়েছে। FK ছাড়া এই ভুলগুলো ঠিকঠাক দেখায় যতক্ষণ না রিপোর্টিং, ইনভয়েসিং বা সাপোর্ট কাজ ভেঙে পড়ে।

UI প্যাটার্ন সরল: free text না দিয়ে নিরাপদ পছন্দ দিন। “Customer” এর জন্য text input এর বদলে একটি select, search, বা autocomplete ব্যবহার করুন যা ব্যাকগ্রাউন্ডে কাস্টমারের ID সংরক্ষণ করে। নো-কোড বিল্ডারে (উদাহরণস্বরূপ AppMaster UI কম্পোনেন্ট ব্যবহার করে) সাধারণত এটা মানে dropdown বা search list কে Customers টেবিলের সাথে বাইন্ড করা এবং লেবেলের বদলে সিলেক্ট করা রেকর্ড রেফারেন্স সেভ করা।

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

• সম্পর্কিত রেকর্ড থাকার সময় মুছতে দেবেন না (কাস্টমার, প্রোডাক্ট, ডিপার্টমেন্টের জন্য সাধারণ)
• ড্রপ করার বদলে আর্কাইভ করুন (রিলেশন ভাঙায় ছাড়া ইতিহাস রাখুন)
• কেবল সেই অবস্থায় cascade delete করুন যখন সত্যিই নিরাপদ (ব্যবসায়িক ডেটার জন্য বিরল)
• সম্পর্ক ঐচ্ছিক হলে রেফারেন্স খালি করুন

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

যদি FK ব্যর্থ হয়, কাঁচা ডাটাবেস মেসেজ দেখাবেন না। স্পষ্টভাবে বলুন: “অনুগ্রহ করে একটি বিদ্যমান কাস্টমার নির্বাচন করুন (নির্বাচিত কাস্টমারটি আর বিদ্যমান নেই)।” সেই এক বাক্যেই ভাঙা সম্পর্ক ছড়ানো থেকে আটকাবে।

UI ফ্লোতে কনস্ট্রেইন্ট ব্যর্থতা হ্যান্ডলিং

ভাল ফর্ম ভুলগুলো আগে ধরে, কিন্তু তারা শেষ বিচারক ভাবতে চায় না। UI ব্যবহারকারীকে দ্রুত কাজ করতে সাহায্য করে; ডাটাবেস নিশ্চিত করে কোনো খারাপ জিনিস সেভ হবে না।

ক্লায়েন্ট-সাইড চেকগুলো চোখে পড়ার মতো বিষয়গুলোর জন্য: রিকুইয়ার্ড ফিল্ড খালি, ইমেইলে ‘@’ নেই, অথবা একটি সংখ্যা অতিরিক্ত বড়। এগুলো দ্রুত দেখালে ফর্ম রেসপনসিভ লাগে এবং ব্যর্থ সাবমিশন কমে।

সার্ভার-সাইড চেকই কনস্ট্রেইন্টগুলোকে প্রকৃত কাজ করায়। UI মিস করলেও (অথবা দুইজন একই সময় সাবমিট করলেও), ডাটাবেস ডুপ্লিকেট, অবৈধ মান, এবং ভাঙা সম্পর্ক ব্লক করে।

যখন সার্ভার থেকে কনস্ট্রেইন্ট ত্রুটি আসে, প্রতিক্রিয়া পূর্বানুমানযোগ্য রাখুন:

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

শেষে, কি ঘটেছে তা লগ করুন যাতে আপনি ফর্ম উন্নত করতে পারেন। কনস্ট্রেইন্ট নাম, টেবিল/ফিল্ড, এবং ব্যবহারকারীর কর্ম ধরা উচিত। যদি একটি কনস্ট্রেইন্ট বারবার ব্যর্থ হয়, UI-তে একটি ছোট হিন্ট যোগ করুন বা একটি অতিরিক্ত ক্লায়েন্ট-সাইড চেক দিন। হঠাৎ বেড়ে যাওয়া এমন ব্যর্থতা একটি বিভ্রান্তিকর স্ক্রিন বা ভাঙা ইন্টিগ্রেশনও নির্দেশ করতে পারে।

উদাহরণ: একটি অভ্যন্তরীণ অর্ডার ফর্ম যা সময়ের সাথে পরিষ্কার থাকে

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

পরিষ্কারভাবে বানানোর উপায় হলো ডাটাবেস নিয়মকে UI-কে নেতৃত্ব দেওয়া। ফর্ম এমন একটি বন্ধুত্বপূর্ণ ফ্রন্টএন্ড হয়ে ওঠে যেগুলো নিয়মগুলো ধরে রাখে, এমনকি কেউ ডেটা ইম্পোর্ট করে বা অন্য কোথাও থেকে রেকর্ড এডিট করলে।

Order টেবিল যা এনফোর্স করে:

• Unique order number: প্রতিটি order_number আলাদা হতে হবে।
• সবসময়-সত্য চেক: quantity > 0, unit_price >= 0, এবং হয়ত unit_price <= 100000।
• Foreign key to Customer: প্রতিটি অর্ডারকে একটি বাস্তব কাস্টমার রেকর্ডের দিকে নির্দেশ করতে হবে।

এখন বাস্তবে কী ঘটে দেখুন।

এক জন রিপ মনে করেই একটি অর্ডার নম্বর টাইপ করে এবং ভুলক্রমে একইটি পুনরায় ব্যবহার করে। সেভটি unique কনস্ট্রেইন্টে ব্যর্থ হয়। অস্পষ্ট “save failed” বলে দেয়ার বদলে UI-তে দেখানো যায়: “Order number ইতিমধ্যেই আছে। পরবর্তী উপলভ্য নম্বর ব্যবহার করুন অথবা বিদ্যমান অর্ডার সার্চ করুন।”

পরে, একটি কাস্টমার রেকর্ড মার্জ বা মুছে ফেলা হয় যখন কারো কাছে ফর্ম খোলা আছে। তারা পুরনো কাস্টমার নিয়ে সেভ করলে foreign key সেটি ব্লক করে। একটি ভালো UI প্রতিক্রিয়া হতে পারে: “এই কাস্টমারটি আর পাওয়া যাচ্ছে না। কাস্টমার তালিকাটি রিফ্রেশ করুন এবং অন্যটি নির্বাচন করুন।” তারপর আপনি Customer dropdown রিলোড করতে পারেন এবং বাকী ফর্ম অক্ষত রাখেন যাতে ব্যবহারকারীর কাজ হারায় না।

সময় ধরে এই প্যাটার্ন অর্ডারগুলো কনসিস্টেন্ট রাখে এমনকি সবাই প্রতিদিন সাবধানে না হলেও।

বিভ্রান্তিকর ত্রুটি ও ময়লা ডেটার দিকে নিয়ে যাওয়া সাধারণ ভুলগুলো

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

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

আপডেটগুলো প্রায়ই উপেক্ষিত হয়। এডিটের সময়ে unique collision ক্লাসিক সমস্যা: একজন ব্যবহারকারী রেকর্ড খোলে, একটি অনন-সম্পর্কিত ফিল্ড পরিবর্তন করে এবং সেভ ব্যর্থ হয় কারণ কোথাও অন্যত্র একটি “unique” মান পরিবর্তিত হয়েছে। স্ট্যাটাস ট্রান্সিশনও একটি ফাঁদ—যদি একটি রেকর্ড Draft থেকে Approved থেকে Cancelled যেতে পারে, নিশ্চিত করুন চেকগুলো পুরো পথটাকে অনুমোদন করে, কেবল চূড়ান্ত অবস্থাকে না।

ফরেন কি সবচেয়ে এড়ানোযাগ্য ভুল হয়: ব্যবহারকারীদের ID টাইপ করতে দেওয়া। যদি UI সম্পর্কের জন্য free text রাখে, আপনি ভাঙা সম্পর্ক পাবেন। রিলেটেড রেকর্ডগুলোর জন্য পিকার ব্যবহার করুন এবং ডাটাবেস কনস্ট্রেইন্টকে ব্যাকস্টপ হিসেবে রাখুন।

অবশেষে, কাঁচা ডাটাবেস ত্রুটি প্যানিক এবং সাপোর্ট টিকিট তৈরি করে। আপনি কড়াকড়া কনস্ট্রেইন্ট রাখতে পারেন এবং তবুও মানবীয় বার্তা দেখাতে পারেন।

সংক্ষিপ্ত ফিক্স তালিকা:

• কনস্ট্রেইন্টগুলো সোর্স অব ট্রুথ রাখুন, কেবল ফর্ম নিয়ম নয়
• বাস্তব ওয়ার্কফ্লো বুঝে চেক ডিজাইন করুন, Ausnahme (exception) সহ
• শুধু “create” নয়, আপডেট ও ট্রানজিশনগুলোও হ্যান্ডল করুন
• সম্পর্কের জন্য টাইপ করা ID নয়, পিকার ব্যবহার করুন
• কনস্ট্রেইন্ট ব্যর্থতাকে বন্ধুত্বপূর্ণ, ফিল্ড-লেভেল বার্তায় ম্যাপ করুন

নো-কোড টিমগুলোর জন্য দ্রুত চেকলিস্ট ও পরবর্তী ধাপ

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

লঞ্চের আগে দ্রুত চেকগুলো

প্রতিটি ফর্মের জন্য যে আপনার ডাটাবেসে লেখে, এই চেকগুলো চালান:

• ডুপ্লিকেট: কোনগুলো ইউনিক হতে হবে (ইমেইল, অর্ডার নম্বর, এক্সটার্নাল ID) চিহ্নিত করে unique নিয়ম আছে কি না নিশ্চিত করুন
• অনুপস্থিত সম্পর্ক: প্রতিটি রিকুইর্ড রিলেশন এনফোর্সড আছে কি না নিশ্চিত করুন (উদাহরণ: একটি Order-এ একটি Customer থাকতে হবে)
• অবৈধ রেঞ্জ: বাউন্ডেড মানের জন্য চেক যোগ করুন (quantity > 0, discount between 0 and 100)
• রিকুইর্ড ফিল্ড: “অবশ্যই থাকা” ডেটা ডাটাবেস লেভেলে নিশ্চিত করুন, কেবল UI required ফ্ল্যাগ নয়
• নিরাপদ ডিফল্ট: কি অটো-ফিল হবে (status = "Draft") সিদ্ধান্ত নিন যাতে মানুষ অনুমান না করে

তারপর ব্যবহারকারীর মতো টেস্ট করুন, নির্মাতার মতো নয়: একটি ক্লিন সাবমিশন end-to-end করুন, তারপর ডুপ্লিকেট, মিসিং রিলেশন, রেঞ্জের বাইরে নম্বর, ফাঁকা রিকুইর্ড ফিল্ড এবং ভুল টাইপ ইনপুট দিয়ে ভাঙে দেখুন।

AppMaster-এ পরবর্তী ধাপ

আপনি যদি AppMaster-এ নির্মাণ করছেন (appmaster.io), প্রথমে Data Designer-এ নিয়ম মডেল করুন (unique, check, এবং foreign keys), তারপর ওয়েব/মোবাইল UI বিল্ডারে ফর্ম বানান এবং Business Process Editor-এ সেভ লজিক কানেক্ট করুন। যখন কোনো কনস্ট্রেইন্ট ব্যর্থ হয়, ত্রুটিটি ধরুন এবং সেটিকে একটি স্পষ্ট ক্রিয়া-নির্দেশে ম্যাপ করুন: কি পরিবর্তন করবেন এবং কোথায়।

ত্রুটি টেক্সট ধারাবাহিক ও শান্ত রাখুন। বর্বরতা এড়ান। "Use a unique email address"-এর পরিবর্তে "Email invalid" না লিখুন। সম্ভব হলে কনফ্লিক্টিং মান বা প্রয়োজনীয় রেঞ্জ দেখান যাতে ঠিক করা সহজ হয়।

একটি বাস্তব ফর্ম (যেমন “Create Customer” বা “New Order”) নির্বাচন করুন, সেটি end-to-end তৈরি করুন, তারপর দলীয় দিন-দিনের কাজ থেকে আসা ময়লা নমুনা ডেটা দিয়ে ভাঙে দেখুন।