অ্যাপ বিল্ড দুই-তিনবার রিডিজাইন হলেও ডাটাবেস দশক ধরে টিকে থাকে। জানুন কেন ডেটা দীর্ঘস্থায়ী হয়, মাইগ্রেশন কেন ব্যয়বহুল, এবং কীভাবে এমন স্কিমা ডিজাইন করবেন যা নিরাপদে বিবর্তিত হয়।
আপনি যদি কয়েক বছর সফটওয়্যারের সাথে কাজ করে থাকেন, সম্ভবত একই কাহিনি বারবার দেখেছেন: অ্যাপ রিডিজাইন, পুনরায় লেখা, রিব্র্যান্ড—বা সম্পূর্ণ প্রতিস্থাপিত—আর ডাটাবেস নীরবভাবে চলতে থাকে।
একটি কোম্পানি ডেক্সটপ অ্যাপ থেকে ওয়েব-অ্যাপে যেতে পারে, তারপর মোবাইল, তারপর নতুন ফ্রেমওয়ার্ক দিয়ে “v2” বানায়। তবুও গ্রাহক রেকর্ড, অর্ডার, চালান এবং প্রোডাক্ট ক্যাটালগ প্রায়ই একই ডাটাবেসে (বা তার সরাসরি উত্তরাধিকারী) থেকে যায়, কখনো কখনো এমন টেবিলগুলির সাথে যা দশ বছর পুরনো।
সরল ভাষায়: অ্যাপ্লিকেশন কোড হলো ইন্টারফেস ও আচরণ, এবং এটি প্রায়ই পরিবর্তিত হয় কারণ প্রতিস্থাপন মোটামুটি সহজ। ডাটাবেস হলো স্মৃতি, এবং এটি বদলানো ঝুঁকিপূর্ণ কারণ ব্যবসা এখানকার ইতিহাসের উপর নির্ভর করে।
একটি সাধারণ অ-টেকনিক্যাল উদাহরণ: আপনি একটি দোকান সংস্কার করতে পারেন—নতুন তাক, নতুন চেকআউট কাউন্টার, নতুন সাইনেজ—তবুও ইনভেন্টরি রেকর্ড ও রশিদ ফেলে দেবার দরকার নেই। সংস্কারটি অ্যাপ; রেকর্ডগুলো হলো ডাটাবেস।
একবার আপনি এই প্যাটার্ন টেনে নেবেন, তখন আপনার সিদ্ধান্ত নেওয়ার ধরন বদলে যাবে:
নিচের অংশগুলোতে আপনি শিখবেন কেন ডাটাবেস দীর্ঘস্থায়ী হয়, কেন ডেটা কোডের চেয়ে সরাতে কঠিন, এবং কীভাবে স্কিমা ও অপারেশন ডিজাইন করলে ডাটাবেস একাধিক অ্যাপ রিরাইট বাঁচিয়ে রাখতে পারে—বিনা প্রতিটি পরিবর্তনকে সঙ্কট বানিয়ে না।
অ্যাপ্লিকেশনরা প্রোডাক্টের মতো মনে হতে পারে, কিন্তু যেখানে প্রোডাক্ট কি ঘটেছে তা মনে রাখে সেটা হল ডাটাবেস।
একটি শপিং অ্যাপ পাঁচবার রিডিজাইন হতে পারে, তবুও গ্রাহকরা তাদের কেনার ইতিহাস সেখানে থাকার আশায় থাকেন। একটি সাপোর্ট পোর্টাল ভেন্ডর বদলে ফেললেও টিকিট, রিফান্ড এবং করা প্রতিশ্রুতির রেকর্ড কনসিস্টেন্ট থাকতে হবে। সেই ধারাবাহিকতা সংরক্ষিত থাকে স্টোরড ডেটায়: গ্রাহক, অর্ডার, চালান, সাবস্ক্রিপশন, ইভেন্ট, এবং তাদের সম্পর্ক।
যদি একটি ফিচার অদৃশ্য হয়ে যায়, ব্যবহারকারীরা বিরক্ত হবে। যদি ডেটা হারায়, আপনি বিশ্বাস, আয় এবং আইনি ভিত্তি হারাতে পারেন।
একটি অ্যাপ প্রায়ই সোর্স কন্ট্রোল ও ডকুমেন্টেশন থেকে পুনর্নির্মাণ করা যায়। বাস্তব-জগতের ইতিহাস তা নয়। আপনি গত বছরের পেমেন্টগুলো “পুনরায় চালাতে” পারবেন না, একটি গ্রাহকের সম্মতি দেওয়ার মুহূর্তে আংশিকভাবে পুনরায় তৈরি করতে পারবেন না, বা ঠিক কী পাঠানো হল ও কখন তা স্মৃতি থেকে পুরো প্রকৃতিতে পুনর্নির্মাণ করা কঠিন। এমনকি আংশিক ক্ষতি—টাইমস্ট্যাম্প মিসিং, অরফান রেকর্ড, অসমঞ্জস টোটাল—পণ্যের নির্ভরযোগ্যতা কমিয়ে দিতে পারে।
অধিকাংশ ডেটা যত দীর্ঘ থাকবে ততই উপযোগী হয়ে ওঠে:
এই কারণেই টিমগুলো ডেটাকে একটি সম্পদ হিসেবে আচরণ করে, উপপ্রোডাক্ট হিসেবে নয়। একটি নতুন অ্যাপ রিরাইট আভিজাত্যপূর্ণ UI দিতে পারে, কিন্তু বছরজুড়ে জমে থাকা ইতিহাস কমই বদলে দেয়।
সময়ের সাথে সংস্থা গোপনে ডাটাবেসকে শেয়ার করা রেফারেন্স পয়েন্ট হিসেবে স্ট্যান্ডার্ড করে তোলে: স্প্রেডশিট এক্সপোর্ট হয়, ড্যাশবোর্ড তার ওপর তৈরি হয়, ফাইন্যান্স প্রসেস সেটা অনুকরণ করে, এবং “নোওন-গুড” কুয়েরি ব্যবহার করা হয় পুনরাবৃত্ত প্রশ্নের উত্তর দিতে।
এটাই ডাটাবেস স্থায়িত্বের আবেগগত কেন্দ্র: ডাটাবেসই স্মৃতি হয়ে ওঠে যার ওপর সবাই নির্ভর করে—অ্যাপ যাই হোক পরিবর্তিত হলেও।
একটি ডাটাবেস দুর্লভভাবে কেবল একটি অ্যাপ্লিকেশনের মালিকানাধীন হয় না। সময়ের সাথে এটি একাধিক প্রোডাক্ট, ইন্টার্নাল টুল ও টিমের জন্য শেয়ার্ড সোর্স অফ ট্রুথ হয়ে ওঠে। সেই শেয়ার্ড নির্ভরতাই একটি বড় কারণ কেন ডাটাবেসগুলি টিকে থাকে যখন অ্যাপলিকেশন কোড বদলে দেয়া হয়।
একই টেবিল সেট সাধারণত সেবা দেয়:
প্রতিটি কনজিউমার বিভিন্ন ভাষায় নির্মিত হতে পারে, আলাদা রিলিজ শিডিউলে চলে, এবং বিভিন্ন মানুষ দ্বারা বজায় রাখা হতে পারে। যখন একটি অ্যাপ রিরাইট হয়, সেটি দ্রুত নিজের কোডকে মানিয়ে নিতে পারে—কিন্তু তখনও এটিই দরকার যে একই রেকর্ডগুলো পড়বে ও সংরক্ষণ করবে যেগুলোর ওপর সবাই নির্ভর করে।
ইন্টিগ্রেশনগুলো প্রায়ই নিজেদের নির্দিষ্ট ডেটা মডেলে বাঁধে: টেবিল নাম, কলাম অর্থ, রেফারেন্স ID, এবং একটি রেকর্ড কী বোঝায় সে সম্পর্কে অনুমান। যদিও ইন্টিগ্রেশন টেকনিক্যালি একটি API-র মাধ্যমে, API প্রায়ই নিচের ডাটাবেস মডেলকেই প্রতিফলিত করে।
এ কারণেই ডাটাবেস পরিবর্তন একটি একক-টিম সিদ্ধান্ত নয়। একটি স্কিমা পরিবর্তন এক্সপোর্ট, ETL জব, রিপোর্ট কুয়েরি, এবং ডাউনস্ট্রিম সিস্টেমে প্রভাব ফেলতে পারে যেগুলো প্রধান প্রোডাক্ট রেপোতে নেই।
যদি আপনি একটি বাগি ফিচার শিপ করেন, আপনি তা রোলব্যাক করবেন। যদি আপনি একটি শেয়ার্ড ডাটাবেস কনট্রাক্ট ভাঙেন, আপনি বিলিং, ড্যাশবোর্ড এবং রিপোর্টিং একসাথে ব্যাহত করতে পারেন। ঝুঁকি নির্ভরশীলদের সংখ্যার দ্বারা গুণিত হয়।
এটিই কারণ যে “অস্থায়ী” পছন্দগুলো (একটি কলামের নাম, একটি enum মান, NULL-এর অদ্ভুত অর্থ) স্থায়ী হয়ে যায়: অনেক কিছু সেগুলোর ওপর নির্ভর করে।
প্র্যাকটিক্যাল স্ট্র্যাটেজির জন্য দেখুন /blog/schema-evolution-guide।
অ্যাপ্লিকেশন কোড প্রায়ই টুকরো করে প্রতিস্থাপন করা যায়। আপনি UI পরিবর্তন করতে পারেন, একটি সার্ভিস প্রতিস্থাপন করতে পারেন, বা একটি ফিচারকে API-এর পেছনে আরঙানি করে পুনর্নির্মাণ করতে পারেন একই ডাটাবেস রেখে। কিছু ভুল হলে আপনি ডেপ্লয় রোলব্যাক করতে পারেন, ট্রাফিক পুরোনো মডিউলে রুট করতে পারেন, বা পুরোনো ও নতুন কোড সাইড-বাই-সাই চালাতে পারেন।
ডেটা আপনাকে একই নমনীয়তা দেয় না। ডেটা শেয়ার্ড, আন্তঃসংযোগিত, এবং সাধারণত প্রত্যেক সেকেন্ডে সঠিক থাকার প্রত্যাশা করা হয়—নট “পরের ডেপ্লয়ের পরে সাধারণত সঠিক।”
যখন আপনি কোড রিফ্যাক্টর করেন, আপনি নির্দেশ পরিবর্তন করছেন। যখন আপনি ডেটা মাইগ্রেট করেন, আপনি ব্যবসা যা নির্ভর করে তা বদলাচ্ছেন: গ্রাহক রেকর্ড, ট্রানজ্যাকশন, অডিট ট্রেইল, প্রোডাক্ট ইতিহাস।
একটি নতুন সার্ভিস কিছু ইউজারের সাবসেটে টেস্ট করা যায়। একটি নতুন ডাটাবেস মাইগ্রেশন সবকিছুকে স্পর্শ করে: বর্তমান ব্যবহারকারী, পুরোনো ব্যবহারকারী, ঐতিহাসিক সারি, অরফান রেকর্ড, এবং তিন বছর আগের এক বাগ দ্বারা তৈরি একক-অফ এন্ট্রি।
একটি ডেটা মুভ কেবল “এক্সপোর্ট ও ইম্পোর্ট” নয়। এটি সাধারণত অন্তর্ভুক্ত করে:
প্রতিটি ধাপ যাচাই প্রয়োজন, এবং যাচাই সময় নেয়—বিশেষত যখন ডেটাসেট বড় এবং ত্রুটির পরিণতি গুরুতর।
কোড ডেপ্লয়মেন্ট ঘন ঘন ও রিভার্সিবল হতে পারে। ডেটা কাটওভারগুলোক শল্যচিকিৎসার মতো।
যদি আপনি ডাউনটাইমের প্রয়োজন করেন, আপনি ব্যবসায়িক অপারেশন, সাপোর্ট এবং গ্রাহক প্রত্যাশা সমন্বয় করবেন। নেয়-জিরো ডাউনটাইম লক্ষ্য করলে আপনি সম্ভবত ডুয়াল-রাইট, চেঞ্জ ডেটা ক্যাপচার, বা সতর্কভাবে পর্যায়ক্রমিক রেপ্লিকেশন করবেন—আর কি হবে যদি নতুন সিস্টেম ধীর বা ভুল হয় তার পরিকল্পনাও থাকবে।
রোলব্যাকও ভিন্ন। কোড রোলব্যাক সহজ; ডেটা রোলব্যাক প্রায়ই ব্যাকআপ রিস্টোর করা, পরিবর্তনগুলো পুনরায় চালানো, বা মেনে নেওয়াই যে কিছু লেখা “ভুল” জায়গায় হয়েছে এবং পুনর্মিলন করা লাগবে।
ডাটাবেসে ইতিহাস জমে: অদ্ভুত রেকর্ড, লিগ্যাসি স্ট্যাটাস, আংশিক মাইগ্রেটেড সারি, এবং কেউ-ই মনে রাখে না এমন ওয়ার্কঅ্যারاؤن্ড। এই এজ কেসগুলো ডেভেলপমেন্ট ডেটাসেটে দারুণভাবে খোঁজায় না, কিন্তু বাস্তব মাইগ্রেশনে তা অবিলম্বে উঠে আসে।
এ কারণেই সংগঠনগুলো প্রায়ই কোড পুনরায় লেখাকে গ্রহণ করে (এমনকি বহুবার), কিন্তু ডাটাবেসকে স্থির রাখে। ডাটাবেস কেবল একটি নির্ভরতা নয়—এটি নিরাপদে বদলানোর সবচেয়ে কঠিন জিনিস।
অ্যাপ কোড পরিবর্তন মূলত নতুন আচরণ শিপ করা। যদি কিছু ভুল হয়, আপনি ডেপ্লয় রোলব্যাক করতে পারেন, ফিচার-ফ্ল্যাগ লাগিয়ে দিতে পারেন, বা দ্রুত প্যাচ করতে পারেন।
একটি স্কিমা পরিবর্তন ভিন্ন: এটি ইতিমধ্যেই থাকা ডেটার জন্য নিয়ম রূপান্তর করে, এবং সেই ডেটা বছরজড়িত, অসমঞ্জস, বা একাধিক সার্ভিস ও রিপোর্টের ওপর নির্ভরশীল হতে পারে।
ভাল স্কিমাগুলি খুব কমই স্থির থাকে। চ্যালেঞ্জ হল সেগুলোকে এমনভাবে উন্নীত করা যাতে ঐতিহাসিক ডেটা বৈধ ও ব্যবহারযোগ্য থাকে। কোডের মতো ডেটা “রিকম্পাইল” করা যায় না—আপনাকে প্রতিটি পুরোনো সারি সামনে নিয়ে যেতে হয়, এমনকি সেসব এজ কেসও যেগুলো কেউ মনে রাখে না।
এই কারণেই স্কিমা বিবর্তন সেই পরিবর্তনগুলোকে অগ্রাধিকার দেয় যা বিদ্যমান অর্থগুলো সংরক্ষণ করে এবং যা ইতিমধ্যেই সংরক্ষিত জিনিসকে পুনর্লিখতে বাধ্য করে না।
অ্যাডিটিভ পরিবর্তন (নতুন টেবিল, নতুন কলাম, নতুন ইনডেক্স) সাধারণত পুরোনো কোডকে কাজ চালিয়ে যেতে দেয় যখন নতুন কোড নতুন গঠন ব্যবহার করে।
ভাঙা পরিবর্তন—একটি কলামের নাম বদলানো, টাইপ পরিবর্তন, একটি ফিল্ডকে কয়েকটি ভাগে ভাগ করা, সীমাবদ্ধতা কঠোর করা—অften সমন্বিত আপডেট দরকার:
প্রধান অ্যাপ আপডেট করলেও, ভুলে যাওয়া একটি রিপোর্ট বা ইন্টিগ্রেশন পুরনো আকৃতির উপর নির্ভর করতে পারে।
“শুধু স্কিমা বদলান” সহজ শোনায় যতক্ষণ না আপনাকে মিলিয়ন মিলিয়ন বিদ্যমান সারি মাইগ্রেট করতে হয় সিস্টেম অনলাইনে রেখেই। আপনাকে ভাবতে হবে:
NOT NULL কলামের জন্য ব্যাকফিল করাALTER অপারেশনের সময় দীর্ঘ-চলমান লক বা টাইমআউট এড়ানোঅনেক ক্ষেত্রে আপনি মাল্টি-স্টেপ মাইগ্রেশন করেন: নতুন ফিল্ড যোগ, উভয় লেখার জন্য কোড পরিবর্তন, ব্যাকফিল, রিড স্যুইচ, তারপর পরে পুরনো ফিল্ড অবসরপ্রাপ্ত করা।
কোড পরিবর্তন রিভার্সিবল ও বিচ্ছিন্ন; স্কিমা পরিবর্তন স্থায়ী ও শেয়ার্ড। একবার একটি মাইগ্রেশন রান করলে তা ডাটাবেসের ইতিহাসের অংশ হয়ে যায়—এবং ভবিষ্যতের প্রতিটি সংস্করণকে সেই সিদ্ধান্তের সঙ্গে সঙ্গে বেঁচে থাকতে হয়।
অ্যাপ ফ্রেমওয়ার্ক দ্রুত চক্রায়: পাঁচ বছর আগে যা “আধুনিক” মনে হচ্ছিল তা আজ সমর্থিত নয়, জনপ্রিয় নয়, বা ভাড়া নিয়ে পাওয়া কঠিন হতে পারে। ডাটাবেসও বদলে যায়, তবে অনেক মূল ধারণা—এবং দৈনন্দিন দক্ষতাগুলি—অনেক ধীরগতিতে চলে।
SQL ও রিলেশনাল কনসেপ্ট দশক ধরে আশ্চর্যজনকভাবে স্থিতিশীল: টেবিল, জয়েন, কন্সট্রেইন্ট, ইনডেক্স, ট্রানজ্যাকশন এবং কুয়েরি প্ল্যান। ভেন্ডররা ফিচার যুক্ত করে, তবু মানসিক মডেল পরিচিত থাকে। সেই স্থিতিশীলতা মানে টিমরা নতুন ভাষায় অ্যাপ রিটাইপ করতে পারলেও একই ডেটা মডেল ও কুয়েরি পদ্ধতি রাখতে পারে।
ন Even নতুন ডাটাবেস প্রোডাক্টগুলোও প্রায়ই এই পরিচিত কুয়েরি ধারণাগুলো ধরে রাখে—“SQL- মতো” লেয়ার, রিলেশনাল-স্টাইল জয়েন, বা ট্রানজ্যাকশন সেমান্টিক্স—কারণ এগুলো রিপোর্টিং, ত্রুটিনিরূপণ ও ব্যবসায়িক প্রশ্নের সাথে ভাল ম্যাপ হয়।
মূলগুলো কন্সিস্টেন্ট থাকায় পারিপার্শ্বিক ইকোসিস্টেম প্রজন্মের পর প্রজন্ম বহন করে:
এই ধারাবাহিকতা “ফোর্সড রিরাইট” কমায়। একটি কোম্পানি অ্যাপ ফ্রেমওয়ার্ক ছেড়ে দিতে পারে কারণ হায়ারিং কঠিন বা সিকিউরিটি প্যাচ বন্ধ—কিন্তু SQL-কে সাধারণ ডেটা ভাষা হিসেবে সাধারণত পরিত্যাগ করে না।
ডাটাবেস স্ট্যান্ডার্ড ও কনভেনশন একটি সাধারণ বেসলাইন তৈরি করে: SQL ডায়ালেক্টগুলি সমান নয়, তবু সেগুলো অধিকাংশ ওয়েব ফ্রেমওয়ার্কের তুলনায় একে অপরের কাছাকাছি। ফলে অ্যাপ লেয়ার বিবর্তিত হলেও ডাটাবেসকে স্থির রাখাটা সহজ হয়।
প্র্যাকটিকাল প্রভাব সরল: যখন টিম অ্যাপ রিরাইট পরিকল্পনা করে, তারা প্রায়ই বিদ্যমান ডাটাবেস দক্ষতা, কুয়েরি প্যাটার্ন ও অপারেশন পদ্ধতি রেখে দিতে পারে—তাই ডাটাবেসই স্থিতিশীল ভিত্তি হয়ে ওঠে যা বহু কোড প্রজন্মকে ছাড়িয়ে যায়।
অধিকাংশ টিম একই ডাটাবেস রাখে কারণ তারা এটিতে কাজ করা অভ্যাস তৈরি করেছে—প্রতিস্থাপনের কারণটা ভালোবাসা নয়। একবার ডাটাবেস প্রোডাকশনে এলে এটি কোম্পানির “অ্যালওয়েজ-অন” মেশিনারির অংশ হয়ে ওঠে। এটিই লোকজন 2টা সকালে পেজ করে, অডিটরা জিজ্ঞেস করে, এবং প্রতিটি নতুন সার্ভিস শেষ পর্যন্ত কথা বলে।
এক বছর দুই পরে টিম সাধারণত একটি নির্ভরযোগ্য রিদম পায়:
ডাটাবেস প্রতিস্থাপন মানে বাস্তবে লোডের নিচে সবকিছু আবার শিখতে হবে, বাস্তব গ্রাহক প্রত্যাশা সহ।
ডাটাবেস যুদ্ধ-পরিচালিত নয়। সময়ের সাথে টিম একটি রিলায়েবিলিটি জ্ঞানের ক্যাটালগ গঠন করে:
সেই জ্ঞান ড্যাশবোর্ড, স্ক্রিপ্ট, এবং লোকেদের মাথার মধ্যে থাকে—কোনো এক ডকুমেন্টে নয়। অ্যাপ কোড রিরাইট করলে আচরণ রাখা যায়, আর ডাটাবেস সার্ভ করে থাকে। ডাটাবেস প্রতিস্থাপন করলে আপনাকে একই সঙ্গে আচরণ, পারফর্ম্যান্স ও রিলায়েবিলিটি পুনর্গঠন করতে হবে।
রোল, অনুমতি, অডিট লগ, সিক্রেট রোটেশন, এনক্রিপশন সেটিং ও “কে কি পড়তে পারে” প্রায়ই কমপ্লায়েন্স ও অভ্যন্তরীণ নীতির সাথে মিলে যায়।
ডাটাবেস বদলালে আপনাকে অ্যাক্সেস মডেল পুনর্নির্মাণ, কন্ট্রোল রিভালিডেট ও ব্যবসার কাছে প্রমাণ করতে হবে যে সংবেদনশীল ডেটা এখনও সুরক্ষিত।
অপারেশনাল পরিণতিমত্তা ঝুঁকি কমায়। নতুন ডাটাবেস যদি ভাল ফিচার বলে, পুরনো ডাটাবেসের কাছে একটি শক্তি থাকে: দীর্ঘদিন স্থায়ী থাকা, রিকভারযোগ্যতা, এবং সমস্যা হলে বোঝার ক্ষমতা।
অ্যাপ কোড প্রতিস্থাপন করা যায় নতুন ফ্রেমওয়ার্ক দিয়ে। তবে কমপ্লায়েন্স বাধ্যবাধকতা রেকর্ডের সাথে সংযুক্ত—কি ঘটেছে, কখন, কে অনুমোদন করেছে, এবং গ্রাহক তখন কী দেখেছিল। এজন্য ডাটাবেস প্রায়ই রিরাইটে অচল্য বস্তু হয়ে যায়।
অনেক ইন্ডাস্ট্রিতে ইনভয়েস, সম্মতি রেকর্ড, আর্থিক ইভেন্ট, সাপোর্ট ইন্টারঅ্যাকশনের জন্য ন্যূনতম রিটেনশন পিরিয়ড থাকে। অডিটররা সাধারণত “আমরা অ্যাপটি রিরাইট করেছি” বলে ইতিহাস হারানোর অজুহাত নেন না।
আপনি হয়তো দৈনন্দিন ব্যবহারে একটি লিগ্যাসি টেবিল আর ব্যবহার না করলেও, অনুরোধে এটি প্রদর্শন করার ও এটি কীভাবে তৈরি হয়েছে বোঝানোর ক্ষমতা রাখতেই হতে পারে।
চার্জব্যাক, রিফান্ড, ডেলিভারি বিরোধ, ও কনট্রাক্ট প্রশ্ন ঐতিহাসিক স্ন্যাপশট নির্ভর করে: সেই সময়ের দাম, যে ঠিকানায় পাঠানো হয়েছিল, গ্রহণকৃত শর্ত, বা নির্দিষ্ট মুহূর্তের স্ট্যাটাস।
যখন ডাটাবেস ঐ তথ্যের অথোরিটেটিভ সোর্স হয়, প্রতিস্থাপন কেবল টেকনিক্যাল প্রকল্প নয়—এটি প্রমাণAlteration-এর ঝুঁকি বাড়ায়। তাই টিমগুলো বিদ্যমান ডাটাবেস রাখে এবং নতুন সার্ভিসগুলো তার উপর নির্মাণ করে, বদলে দেওয়ার চেয়ে।
কিছু রেকর্ড মুছতে পারবেন না; অন্যগুলো এমনভাবে রূপান্তর করা যাবে না যাতে ট্রেসেবিলিটি ভেঙে যায়। যদি আপনি ডিনরমালাইজ করেন, ফিল্ড মার্জ করেন, বা কলাম ড্রপ করেন, আপনি অডিট ট্রেইল পুনর্গঠন করার ক্ষমতা হারাতে পারেন।
এই টেনশন সবচেয়ে স্পষ্ট যখন প্রাইভেসি দাবি রিটেনশনের সাথে জড়ায়: হয় আপনাকে নির্বাচিত রেড্যাকশন বা পসুডোনিমাইজেশন করতে হবে তবুও ট্রানজ্যাকশন ইতিহাস অক্ষত রাখতে হবে। এই সীমাবদ্ধতাগুলো সাধারণত ডেটার সবচেয়ে কাছাকাছি থাকে।
ডেটা ক্লাসিফিকেশন (PII, ফাইন্যান্সিয়াল, হেলথ, অভ্যন্তরীণ) ও গভর্ন্যান্স নীতি সাধারণত স্থিতিশীল থাকে যদিও প্রোডাক্ট বিবর্তিত হয়। অ্যাক্সেস কন্ট্রোল, রিপোর্ট ডেফিনিশন, এবং “সিঙ্গল সোর্স অফ ট্রুথ” সিদ্ধান্তগুলো প্রায়ই ডাটাবেস লেভেলে প্রয়োগ করা হয় কারণ এটি অনেক টুল—BI, ফাইন্যান্স এক্সপোর্ট, রেগুলেটরের রিপোর্ট ও ইনসিডেন্ট ইনভেস্টিগেশনের দ্বারা শেয়ার্ড।
রিরাইট পরিকল্পনা করলে কমপ্লায়েন্স রিপোর্টিংকে প্রথম শ্রেণীর অনুষঙ্গ হিসেবে বিবেচনা করুন: প্রয়োজনীয় রিপোর্ট, রিটেনশন শিডিউল, ও অডিট ফিল্ডগুলোর ইনভেন্টরি করুন স্কিমা স্পর্শ করার আগে। একটি সহজ চেকলিস্ট সহায় করে (দেখুন /blog/database-migration-checklist)।
অধিকাংশ “টেম্পরারি” ডাটাবেস পছন্দ বেকসটাকে আতঙ্কজনকভাবে নেওয়া হয়নি—এগুলো চাপের অধীনে নেওয়া হয়: লঞ্চ ডেডলাইন, জরুরি ক্লায়েন্ট অনুরোধ, নতুন নিয়মাবলি, বা মেসি ইমপোর্ট। আচরণগত আশ্চর্যের বিষয় হল কত বার এসব পছন্দ অনির্বাস্যভাবে অপসারিত হয় না।
অ্যাপ কোড দ্রুত রিফ্যাক্টর করা যায়, কিন্তু ডাটাবেসকে একই সময়ে পুরোনো ও নতুন কনজিউমারদের পরিবেশন করতে হয়। লিগ্যাসি টেবিল ও কলাম লিঙ্গার করে কারণ কিছু এখনও তাদের উপর নির্ভর করে:
এমনকি যদি আপনি একটি ফিল্ড রিনেম করেন, প্রায়ই আপনি পুরনোটাকেও রেখে দেন। একটি সাধারণ প্যাটার্ন হল নতুন কলাম (উদাহরণ: customer_phone_e164) যোগ করা এবং phone অনন্তকালের জন্য রেখে দেওয়া কারণ একটি নাইটলি এক্সপোর্ট এখনও সেটিই ব্যবহার করে।
ওয়ার্কঅ্যারাউন্ডগুলো স্প্রেডশিট, ড্যাশবোর্ড, ও CSV এক্সপোর্টে এম্বেড হয়—যেগুলো বিরলভাবে প্রোডাকশন কোড হিসেবে ট্রিট করা হয়। কেউ একটি রেভিনিউ রিপোর্ট বানায় যে একটি ডিপ্রিকেটেড টেবিল যোগ করে “অবধি ফাইন্যান্স মাইগ্রেট করে।” তারপর ফাইন্যান্সের ত্রৈমাসিক প্রক্রিয়া ও সেই রিপোর্টের উপর নির্ভর করে, এবং ঐ টেবিল মুছা ব্যবসায়িক ঝুঁকি হয়ে ওঠে।
এই কারণেই ডিপ্রিকেটেড টেবিল বছরজুড়ে টিকে থাকতে পারে: ডাটাবেস কেবল অ্যাপ সার্ভ করে না; এটি প্রতিষ্ঠানের অভ্যাসকেও সার্ভ করে।
একটি ফিল্ড যা দ্রুত ফিক্স হিসেবে যোগ করা হয়—promo_code_notes, legacy_status, manual_override_reason—প্রায়ই ওয়ার্কফ্লোতে সিদ্ধান্ত-কারক হয়ে যায়। মানুষ যখন এটি ব্যবহার করে ফলাফল ব্যাখ্যা করতে (“আমরা এই অর্ডারটি অনুমোদন করেছি কারণ…”), তখন এটি আর ঐচ্ছিক থাকে না।
যখন টিমগুলো একটি মাইগ্রেশনে বিশ্বাস করে না, তারা শ্যাডো কপি রাখে: ডুপ্লিকেট করা গ্রাহক নাম, ক্যাশ করা টোটাল, বা ফ্যালব্যাক ফ্ল্যাগ। এই অতিরিক্ত কলামগুলো নিরীহ মনে হলেও তাতে নতুন ট্রুথ সোর্স ও নতুন ডিপেনডেন্সি তৈরি হয়।
এই ফাঁদ থেকে বাঁচতে স্কিমা পরিবর্তনগুলোকে প্রোডাক্ট পরিবর্তনের মতো আচরণ করুন: উদ্দেশ্য ডকুমেন্ট করুন, ডিপেনডেন্সি ট্র্যাক করুন, এবং মুছার আগে অবসর পরিকল্পনা নির্ধারণ করুন। একটি প্র্যাকটিক্যাল চেকলিস্ট দেখতে /blog/schema-evolution-checklist।
একটি ডাটাবেস যা বহু অ্যাপ জেনারেশন টিকে থাকতে চায় সেটিকে একটি অভ্যন্তরীণ ইমপ্লিমেন্টেশন ডিটেইল হিসেবে নয় বরং শেয়ার্ড ইনফ্রাস্ট্রাকচার হিসেবে আচরণ করতে হবে। লক্ষ্য প্রতিটি ভবিষ্যৎ ফিচার ভবিষ্যদ্বাণী করা নয়—এটি হল পরিবর্তনকে নিরাপদ, ধীরগতিতে, এবং রিভার্সিবল করে তোলা।
অ্যাপ কোড রিরাইট করা যায়, কিন্তু ডেটা কনট্রাক্টগুলো পুনরায় মীমাংসা করা কঠিন। টেবিল, কলাম, এবং কী সম্পর্কগুলোকে এমনভাবে ভাবুন যা অন্য সিস্টেম (এবং ভবিষ্যৎ টিম) নির্ভর করবে।
পছন্দ দিন অ্যাডিটিভ পরিবর্তনের:
ভবিষ্যৎ রিরাইট ব্যর্থ হয় না কারণ ডেটা নেই, বরং কারণ তা অস্পষ্ট।
নামগুলো স্পষ্ট ও ধারাবাহিক রাখুন যা উদ্দেশ্য বোঝায় (উদাহরণ: billing_address_id বনাম addr2)। সম্ভব হলে কন্সট্রেইন্টের মাধ্যমে নিয়ম এনকোড করুন: প্রাইমারি কি, ফরেন কি, NOT NULL, ইউনিকনেস, চেক কন্সট্রেইন্ট।
স্কিমার কাছে হালকা ডকুমেন্টেশন রাখুন—টেবিল/কলাম কমেন্ট, বা আপনার অভ্যন্তরীণ হ্যান্ডবুকে লিঙ্ক করা একটি সংক্ষিপ্ত লাইভ ডক। “কেন” বোঝানো “কি” ততটাই গুরুত্বপূর্ণ।
প্রতিটি পরিবর্তনের একটি সামনে যাওয়ার পথ এবং একটি পিছনে ফিরে যাওয়ার পথ থাকতে হবে।
একটি প্র্যাকটিক্যাল উপায় হলো আপনার ডেলিভারি ওয়ার্কফ্লোতে “প্ল্যানিং মোড” ও রোলব্যাক শৃঙ্খলা বেক করা—এর ফলে ডাটাবেস পরিবর্তনের বিস্ফোরণ-রেডিয়াস ছোট হয়। উদাহরণস্বরূপ, যখন টিমগুলো Koder.ai-তে অভ্যন্তরীণ টুল বা নতুন অ্যাপ সংস্করণ বানায়, তারা চ্যাটের মাধ্যমে ইটারেট করতে পারে অথচ স্কিমাকে একটি স্থিতিশীল চুক্তি হিসেবে দেখায়—স্ন্যাপশট ও রোলব্যাক-স্টাইল প্র্যাকটিস ব্যবহার করে দুর্ঘটনার বিস্তার কমায়।
যদি আপনি আপনার ডাটাবেসকে স্থিতিশীল কনট্রাক্ট ও নিরাপদ বিবর্তনের সাথে ডিজাইন করেন, অ্যাপ রিরাইটগুলো রুটিন ইভেন্টে পরিণত হবে—ঝুঁকিপূর্ণ “ডেটা রেসকিউ” মিশন না হয়ে।
ডাটাবেস প্রতিস্থাপন বিরল, কিন্তু কাল্পনিক নয়। যে টিমগুলো সফলভাবে তা করে তারা “সাহসী” নয়—তারা বছরগুলো আগেই প্রস্তুতি নেয়: ডেটা পোর্টেবল রাখা, নির্ভরশীলতাগুলো দৃশ্যমান করা, এবং অ্যাপ্লিকেশনকে এক ইঞ্জিনে শক্তভাবে বাঁধা না করা।
এক্সপোর্টকে একটি প্রথম শ্রেণীর ক্ষমতা হিসেবে আচরণ করা শুরু করুন, একটি এক-অফ স্ক্রিপ্ট না করে।
টাইটো কাপ্লিংই মাইগ্রেশনকে রিরাইটে পরিণত করে।
একটি ব্যালান্সড দৃষ্টিভঙ্গি নিন:
যদি আপনি দ্রুত একটি নতুন সার্ভিস বানান (উদাহরণ: React অ্যাডমিন অ্যাপ + Go ব্যাকএন্ড PostgreSQL), একটি স্ট্যাক বেছে নিন যা পোর্টেবিলিটি ও অপারেশনাল স্পষ্টতাকে ডিফল্ট করে। Koder.ai ঐ বিস্তৃত গৃহীত প্রিমিটিভগুলোর উপর জোর দেয়, এবং এটি সোর্স কোড এক্সপোর্ট সাপোর্ট করে—উপকারী যখন আপনি চান অ্যাপ লেয়ার প্রতিস্থাপনযোগ্য থাকুক কিন্তু ডেটা মডেল একটি ওয়ান-অফ টুলে লক না থাকে।
ডাটাবেস প্রায়ই প্রধান অ্যাপ ছাড়াও আরও অনেককিছু চালায়: রিপোর্ট, স্প্রেডশিট, শেডিউলড ETL জব, থার্ড-পার্টি ইন্টিগ্রেশন, ও অডিট পাইপলাইন।
একটি লাইভ ইনভেন্টরি রাখুন: কে পড়ে/লিখে, কত ঘনঘন, এবং ভেঙে গেলে কি হয়। /docs-এ একটি পৃষ্ঠা মাত্রই অনেক অবাঞ্ছিত বিস্ময় প্রতিরোধ করে।
সাধারণ চিহ্ন: লাইসেন্সিং বা হোস্টিং বাধা, অনিমোধ্যনীয় নির্ভরযোগ্যতা সমস্যা, অনুপস্থিত কমপ্লায়েন্স ফিচার, বা স্কেল সীমা যা চরম ওয়ার্কঅ্যারাউন্ড বাধ্য করে।
প্রধান ঝুঁকি: ডেটা লস, সূক্ষ্ম অর্থ পরিবর্তন, ডাউনটাইম, এবং রিপোর্টিং ড্রিফট।
নিরাপদ পদ্ধতি সাধারণত প্যারালাল রান: ডেটা অবিরত মাইগ্রেট করুন, ফলাফল ভ্যালিডেট করুন (গণনা, চেকসাম, বিজনেস মেট্রিকস), ধীরে ধীরে ট্রাফিক সরান, এবং কনফিডেন্স না হওয়া পর্যন্ত রোলব্যাক পথ রাখুন।
কারণ ডাটাবেস ব্যবসার ঐতিহাসিক সত্য সংরক্ষণ করে (গ্রাহক, অর্ডার, চালান, অডিট ট্রেইল)। কোড পুনরায় ডেপ্লয় বা পুনরায় লিখে ফেলা যায়; কিউরা বা করাপট হওয়া ইতিহাস পুনর্নির্মাণ করা কঠিন এবং তা আর্থিক, আইনি ও বিশ্বাসগত সমস্যা সৃষ্টি করতে পারে।
ডেটা পরিবর্তনগুলি শেয়ার্ড ও স্থায়ী।
একটি একক ডাটাবেস প্রায়ই একক সত্যের উৎস হয়ে ওঠে, যেমন:
অ্যাপটি পুনরায় লিখলেও এসব কনজিউমার স্টেবল টেবিল, ID ও মানগুলির উপর নির্ভর করে।
দুর্লভ নয়। বেশিরভাগ “মাইগ্রেশন” ধাপে করা হয় যাতে ডাটাবেস কনট্রাক্ট স্থিতিশীল থাকে যখন অ্যাপ কম্পোনেন্ট পরিবর্তন হয়।
সাধারণ পদ্ধতি:
অধিকাংশ দল অ্যাডিটিভ পরিবর্তনকে লক্ষ্য করে:
এতে পুরোনো ও নতুন কোড সাইড-বাই-সাই চলতে পারে এবং রূপান্তর সহজ হয়।
অস্পষ্টতা কোডের চেয়েও বেশি দিন টিকে থাকে।
প্রায়োগিক ধাপ:
billing_address_id)।NOT NULL, ইউনিক, চেক)।অদ্ভুত সারি দেখার জন্য প্রস্তুত থাকুন।
মাইগ্রেশনের আগে পরিকল্পনা করুন:
প্রোডাকশন-সদৃশ ডেটার বিরুদ্ধে মাইগ্রেশন টেস্ট করুন এবং কেবল ট্রান্সফর্মেশন লজিক নয়, যাচাই ধাপ অন্তর্ভুক্ত করুন।
কমপ্লায়েন্স রেকর্ডের সাথে সংযুক্ত — UI নয়।
আপনাকে রাখতে বা পুনরুৎপাদন করতে হতে পারে:
ফিল্ড রি-শেপ বা ড্রপ করলে ট্রেসেবিলিটি, রিপোর্ট ডেফিনিশন বা অডিট ক্ষমতা নষ্ট হতে পারে—এমনকি অ্যাপ চলে গেলেও।
কারণ কম্প্যাটিবিলিটি গোপন ডিপেনডেন্সি তৈরি করে:
ডিপ্রেকেশনগুলোকে প্রোডাক্ট পরিবর্তনের মতো আচরণ করুন: উদ্দেশ্য ডকুমেন্ট করুন, কনজিউমার ট্র্যাক করুন, ও অবসর পরিকল্পনা নির্ধারণ করুন।
একটি প্রায়োগিক চেকলিস্ট:
এতে রাইটগুলো রুটিন হয়; ডেটা রেসকিউ প্রকল্পে না পরিণত হয়।