আপনার ডেটা অখণ্ডতা কেন্দ্রীভূত করুন

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

যখন একটি সিস্টেম (যেমন, একটি ডেটাবেস) আর ডেটার আকৃতি প্রয়োগ করতে পারে না, তখন অন্য কিছুকে সেই ঘাটতি পূরণ করতে হবে। এটি কখন ঘটতে পারে?

মার্কিন যুক্তরাষ্ট্রে ফোন নম্বরের ফরম্যাট হল (এলাকা কোড) (প্রিফিক্স) – (নম্বর), এখানে একটি উদাহরণ: (734) 555-3212। আমরা সরলতার জন্য এই নিবন্ধে ডেটাবেস সম্পর্কে কথা বলব, তবে ডেটাস্টোর একটি ডেটাবেস হতে হবে না।

মার্কিন যুক্তরাষ্ট্রে ফোন নম্বরে সর্বদা দশটি সংখ্যা থাকে (আমরা আন্তর্জাতিক সংখ্যা উপেক্ষা করছি)। ফোন নম্বর বিভিন্ন ফরম্যাটে আসতে পারে:

• xxx.xxx.xxxx
• xxx-xxx-xxxx
• (xxx) xxx-xxxx
• (xxx) xxx.xxxx

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

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

যখন আপনার আর্কিটেকচার একটি ডেটাবেস ভাগাভাগি করে দুই বা ততোধিক অ্যাপ্লিকেশনে বৃদ্ধি পায়, তখন দুটি জিনিস ঘটতে পারে:

১. প্রতিটি অ্যাপ্লিকেশনের নিজস্ব ডেটা যাচাইকরণ রয়েছে:

২. একটি কেন্দ্রীয় সেবা রয়েছে যা অ্যাপ্লিকেশনগুলি ডেটা যাচাই করতে এবং ডেটা সংরক্ষণ করতে কল করে:

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

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