डेटाबेस अक्सर दशकों तक टिकते हैं जबकि ऐप्स बार-बार री-राइट होते हैं। जानें क्यों डेटा अधिक समय तक रहता है, माइग्रेशन महँगे क्यों होते हैं, और ऐसे स्कीमा कैसे डिज़ाइन करें जो सुरक्षित रूप से विकसित हो सकें।
अगर आपने कुछ साल सॉफ्टवेयर के आस-पास काम किया है, तो आपने यह कहानी बार-बार देखी होगी: ऐप का redesign, rewrite, rebrand या पूरी तरह से बदल दिया जाता है—जबकि डेटाबेस चुपचाप चलता रहता है।
कम्पनी डेस्कटॉप ऐप से वेब ऐप, फिर मोबाइल, फिर किसी नए फ्रेमवर्क में "v2" तक जा सकती है। फिर भी कस्टमर रिकॉर्ड, ऑर्डर, इनवॉइस और प्रोडक्ट कैटलॉग अक्सर वही रहते हैं (या उनके डायरेक्ट डेसेंडेंट), कभी-कभी दशक पुरानी टेबल्स के साथ।
साधारण शब्दों में: एप्लिकेशन कोड इंटरफ़ेस और व्यवहार है, और यह अक्सर बदलता है क्योंकि इसे बदलना अपेक्षाकृत आसान है। डेटाबेस मेमोरी है, और इसे बदलना जोखिम भरा है क्योंकि यह उस इतिहास को रखता है जिस पर व्यवसाय निर्भर करता है।
एक साधारण गैर-तकनीकी उदाहरण: आप एक दुकान का नवीनीकरण कर सकते हैं—नए शेल्व, नए काउंटर, नए साइन—बिना इन्वेंटरी रिकॉर्ड्स और रसीदों को फेंके। नवीनीकरण ऐप है। रिकॉर्ड्स डेटाबेस हैं।
एक बार जब आप इस पैटर्न को नोटिस कर लेते हैं, तो यह आपके निर्णय बदल देता है:
आगे के सेक्शन्स में आप जानेंगे कि डेटाबेस क्यों टिकते हैं, डेटा को कोड से स्थानांतरित करना कठिन क्यों है, और व्यावहारिक तरीके ताकि स्कीमा सुरक्षित रूप से विकसित हो सके—ताकि डेटाबेस कई एप्लिकेशन री-राइट्स से बच सके बिना हर बदलाव को संकट बना दिए।
ऐप्स प्रोडक्ट जैसा महसूस होते हैं, पर उत्पाद वही याद रखता है जो डेटाबेस में है।
एक शॉपिंग ऐप को पाँच बार redesign किया जा सकता है, फिर भी ग्राहक उम्मीद करते हैं कि उनकी खरीद इतिहास मौजूद होगा। एक सपोर्ट पोर्टल विक्रेता बदल सकता है, फिर भी टिकट, रिफंड और किए गए वादों का रिकॉर्ड लगातार रहना चाहिए। वह निरंतरता स्टोर्ड डेटा में रहती है: कस्टमर्स, ऑर्डर, इनवॉइस, सब्स्क्रिप्शन, इवेंट और उनके बीच के रिश्ते।
अगर एक फीचर गायब हो जाए तो यूज़र्स नाराज़ होते हैं। अगर डेटा गायब हो जाए तो आप भरोसा, राजस्व और कानूनी आधार खो सकते हैं।
एक ऐप अक्सर सोर्स कंट्रोल और डॉक्यूमेंटेशन से फिर बनाया जा सकता है। असली दुनिया का इतिहास नहीं। आप पिछले साल के भुगतान "फिर से चला" नहीं सकते, किसी ग्राहक की सहमति ठीक उसी क्षण पर रीकन्स्ट्रक्ट नहीं कर सकते, या याद से बिल्कुल नहीं बता सकते कि क्या कब शिप हुआ था। यहां तक कि आंशिक नुकसान—मिसिंग टाइमस्टैम्प, ऑर्फन रिकॉर्ड्स, असंगत टोटल—उत्पाद को अविश्वसनीय बना सकता है।
अधिकांश डेटा जितना अधिक समय तक मौजूद रहता है, उतना ही उपयोगी होता है:
यही कारण है कि टीमें डेटा को बायप्रोडक्ट नहीं बल्कि एसेट मानती हैं। एक ताज़ा ऐप री-राइट बेहतर UI दे सकता है, लेकिन यह वर्षों की ऐतिहासिक सच्चाई को शायद ही बदलता है।
समय के साथ, संगठन चुपचाप डेटाबेस को साझा रेफरेंस पॉइंट के रूप में मानक बनाते हैं: उससे एक्सपोर्ट की गई स्प्रेडशीट्स, उस पर बने डैशबोर्ड, फाइनेंस प्रोसेसेज़ की रीकंसाइलिंग, और "नॉउन-गुड" क्वेरीज जो नियमित सवालों के जवाब देती हैं।
यही डेटाबेस दीर्घायु का भावनात्मक केंद्र है: डेटाबेस वह मेमोरी बन जाता है जिस पर हर कोई निर्भर करता है—भले ही उसके चारों ओर का एप्लिकेशन बदलता रहे।
एक डेटाबेस शायद ही कभी सिर्फ़ एक एप्लिकेशन का "मालिक" होता है। समय के साथ, यह कई उत्पादों, आंतरिक टूल्स और टीमों के लिए साझा सोर्स ऑफ ट्रूथ बन जाता है। यही साझा निर्भरता एक बड़ी वजह है कि डेटाबेस ऐप कोड के बदलने के बावजूद टिके रहते हैं।
कई बार एक ही टेबल सेट सेवा देता है:
इनमें से हर एक अलग भाषाओं में बनाया जा सकता है, अलग रिलीज शेड्यूल पर चलता है, और अलग लोगों द्वारा मेंटेन किया जाता है। जब कोई एप्लिकेशन री-राइट होता है, तो वह अपने कोड को जल्दी अनुकूलित कर सकता है—पर उसे फिर भी वही रिकॉर्ड पढ़ने और बरकरार रखने की ज़रूरत होती है जिन पर बाकी सब निर्भर हैं।
इंटीग्रेशन्स खुद को अक्सर किसी विशेष डेटा मॉडल के साथ "बाँध" लेती हैं: टेबल नाम, कॉलम का अर्थ, रेफरेंस IDs, और यह मानना कि एक रिकॉर्ड क्या दर्शाता है। भले ही इंटीग्रेशन तकनीकी रूप से API के माध्यम से हो, API अक्सर नीचे के डेटाबेस मॉडल को प्रतिबिंबित करता है।
इसलिए डेटाबेस बदलना एक टीम का निर्णय नहीं रह जाता। एक स्कीमा परिवर्तन एक्सपोर्ट्स, ETL जॉब्स, रिपोर्टिंग क्वेरीज, और डाउनस्ट्रीम सिस्टम्स में लहरें पैदा कर सकता है जो मुख्य प्रोडक्ट रेपो में भी नहीं हैं।
अगर आप बग वाला फीचर शिप करते हैं, तो आप उसे रोलबैक कर देते हैं। अगर आप एक साझा डेटाबेस कॉन्ट्रैक्ट तोड़ते हैं, तो आप बिलिंग, डैशबोर्ड और रिपोर्टिंग को एक साथ बाधित कर सकते हैं। जोखिम निर्भरताओं की संख्या से गुणा हो जाता है।
इसीलिए "अस्थायी" चुनाव (एक कॉलम नाम, एक enum मान, NULL का अजीब अर्थ) चिपचिपे बन जाते हैं: बहुत सी चीज़ें उन पर चुपचाप निर्भर रहती हैं।
यदि आप सुरक्षित तरीके से प्रबंधित करने की व्यावहारिक रणनीतियाँ चाहते हैं, तो देखें /blog/schema-evolution-guide.
एप्लिकेशन कोड को अक्सर हिस्सों में बदला जा सकता है। आप UI को बदल सकते हैं, एक सर्विस को रिप्लेस कर सकते हैं, या किसी फीचर को API के पीछे पुनर्निर्मित कर सकते हैं—और उसी डेटाबेस को नीचे रख सकते हैं। कुछ गलत होने पर आप deploy रोलबैक कर सकते हैं, ट्रैफ़िक पुराने मॉड्यूल पर वापस रूट कर सकते हैं, या पुराना और नया कोड साथ चला सकते हैं।
डेटा आपको वही लचीलापन नहीं देता। डेटा साझा, इंटरकनेक्टेड रहता है, और आमतौर पर हर सेकंड सही होने की अपेक्षा रहती है—न कि "अगले deploy के बाद ज्यादातर सही"।
जब आप कोड रिफैक्टर करते हैं, आप निर्देश बदल रहे होते हैं। जब आप डेटा माइग्रेट करते हैं, आप उस चीज़ को बदल रहे होते हैं जिस पर व्यवसाय निर्भर करता है: कस्टमर रिकॉर्ड्स, ट्रांज़ैक्शन्स, ऑडिट ट्रेल्स, प्रोडक्ट इतिहास।
एक नई सर्विस को एक सबसर्ज़ट यूज़र्स पर टेस्ट किया जा सकता है। एक नई डेटाबेस माइग्रेशन सब कुछ छूती है: करंट यूज़र्स, पुराने यूज़र्स, ऐतिहासिक रो, ऑर्फन रिकॉर्ड्स और तीन साल पुराने बग की वजह से बने अजीब एक-ऑफ एंट्रीज़।
डेटा मूव सिर्फ "एक्सपोर्ट और इम्पोर्ट" नहीं होता। इसमें सामान्यतः शामिल होता है:
हर स्टेप को वेरिफिकेशन चाहिए, और वेरिफिकेशन समय लेता है—खासतौर पर जब डेटा बड़ा हो और गलती के गंभीर परिणाम हों।
कोड डिप्लॉयमेंट अक्सर बार-बार और उलटने योग्य होते हैं। डेटा कटओवर्स अधिक सर्जिकल होते हैं।
अगर आपको डाउनटाइम चाहिए, तो आप बिजनेस ऑपरेशन्स, सपोर्ट और ग्राहक अपेक्षाओं का समन्वय कर रहे होते हैं। यदि आप नज़दीकी शून्य डाउनटाइम के लिए लक्ष्य रखते हैं, तो आप शायद dual-writes, change data capture, या सावधानीपूर्वक स्टेज्ड रेप्लिकेशन कर रहे होते हैं—और साथ में एक योजना कि नया सिस्टम धीमा या गलत होने पर क्या होगा।
रोलबैक भी अलग होते हैं। कोड रोलबैक आसान है; डेटा रोलबैक अक्सर बैकअप्स को restore करने, परिवर्तन replay करने, या स्वीकार करने का मतलब होता है कि कुछ लेखन "गलत" जगह हुआ और उसे reconcile करना होगा।
डेटाबेस इतिहास जमा करते हैं: अजीब रिकॉर्ड्स, लेगेसी स्टेटस, आंशिक माइग्रेटेड रो, और ऐसी वर्कअराउंड्स जिन्हें कोई याद नहीं रखता। ये एज केसेस डेवलपमेंट डेटासेट में शायद ही दिखें, पर वास्तविक माइग्रेशन के दौरान तुरंत surface होते हैं।
इसीलिए संगठन अक्सर कोड को कई बार री-राइट करने को स्वीकार कर लेते हैं, जबकि डेटाबेस को स्थिर रखते हैं। डेटाबेस सिर्फ़ एक निर्भरता नहीं है—यह सबसे कठिन चीज़ है जिसे सुरक्षित रूप से बदलना है।
एप्लिकेशन कोड बदलना ज्यादातर नया व्यवहार शिप करने का मामला होता है। अगर कुछ गलत हुआ, आप deploy रोलबैक कर सकते हैं, feature-flag लगा सकते हैं, या जल्दी पैच कर सकते हैं।
एक स्कीमा परिवर्तन अलग होता है: यह पहले से मौजूद डेटा के नियमों को बदलता है, और वह डेटा सालों पुराना, असंगत या कई सेवाओं और रिपोर्ट्स पर निर्भर हो सकता है।
अच्छे स्कीमा शायद ही स्थिर रहें। चुनौती यह है कि उन्हें ऐस�ै तरह बदलें कि ऐतिहासिक डेटा वैध और उपयोग योग्य बना रहे। कोड की तरह डेटा को "री-कम्पाइल" नहीं किया जा सकता—आपको हर पुराने रो को आगे ले जाना पड़ता है, जिनमें वे एज केस भी शामिल हैं जिन्हें कोई याद नहीं रखता।
इसीलिए स्कीमा विकास ऐसे बदलावों को तरजीह देता है जो मौजूदा अर्थ को संरक्षित रखें और जोड़े बिना मौजूदा स्टोरेड डेटा को री-राइट करने के लिए मजबूर न करें।
ऐडिटिव बदलाव (नयी टेबल्स, नए कॉलम, नए इंडेक्स) आम तौर पर पुराने कोड को काम करने देते हैं जबकि नया कोड नई संरचना का लाभ उठाता है।
ब्रेकिंग बदलाव—कॉलम का नाम बदलना, प्रकार बदलना, एक फ़ील्ड को कई में बाँटना, कन्स्ट्रेंट्स कड़ा करना—अक्सर समन्वित अपडेट्स की ज़रूरत होती है:
भले ही आप मुख्य ऐप को अपडेट कर दें, एक भुला हुआ रिपोर्ट या इंटीग्रेशन चुपचाप पुराने आकार पर निर्भर कर सकता है।
"बस स्कीमा बदलो" सुनने में सरल लगता है जब तक कि आपको लाखों मौजूदा पंक्तियों को सिस्टम ऑनलाइन रखते हुए माइग्रेट नहीं करना पड़ता। आपको सोचना होगा:
NOT NULL कॉलम्स के लिए बैकफिल वैल्यूज़ALTER ऑपरेशन्स के दौरान लंबे लॉक या टाइमआउट से बचनाअक्सर आप मल्टी-स्टेप माइग्रेशन्स करते हैं: नया फ़ील्ड जोड़ें, दोनों जगह लिखें, बैकफिल करें, पढ़ाई स्विच करें, फिर पुराने फ़ील्ड बाद में रिटायर करें।
कोड बदलाव उलटने योग्य और पृथक होते हैं; स्कीमा बदलाव स्थायी और साझा होते हैं। जब एक माइग्रेशन चलता है, तो वह डेटाबेस के इतिहास का हिस्सा बन जाता है—और हर भविष्य का प्रोडक्ट उस निर्णय के साथ जीना होगा।
एप्लिकेशन फ्रेमवर्क तेज़ी से चक्रवद्ग होते हैं: जो पाँच साल पहले "मॉडर्न" था, आज अप्रयुक्त, अनुपयोगी या हायर करने में कठिन हो सकता है। डेटाबेस भी बदलते हैं, पर कई कोर आइडियाज़—और रोज़मर्रा के कौशल—बहुत धीरे चलते हैं।
SQL और रिलेशनल कॉन्सेप्ट दशकों से आश्चर्यजनक रूप से स्थिर रहे हैं: टेबल्स, जॉइन्स, कन्स्ट्रेंट्स, इंडेक्सेस, ट्रांज़ैक्शन्स और क्वेरी प्लान्स। वेंडर फीचर्स जोड़ते हैं, पर मानसिक मॉडल परिचित रहता है। यह स्थिरता टीमों को किसी नए भाषा में ऐप री-राइट करते समय वही बेसिक डेटा मॉडल और क्वेरी अप्रोच रखने योग्य बनाती है।
नए डेटाबेस उत्पाद भी अक्सर इन परिचित विचारों को संरक्षित करते हैं। आप "SQL- जैसे" क्वेरी लेयर्स, रिलेशनल-स्टाइल जॉइन्स, या ट्रांज़ैक्शन सेमैन्टिक्स देखेंगे क्योंकि वे रिपोर्टिंग, ट्रबलशूटिंग और बिजनेस सवालों से अच्छी तरह मेल खाते हैं।
बेसिक्स स्थिर रहने से आसपास का इकोसिस्टम पीढ़ियों के पार भी बना रहता है:
यह निरंतरता "फोर्स्ड री-राइट्स" को कम करती है। एक कम्पनी ऐप फ्रेमवर्क छोड़ सकती है क्योंकि हायरिंग कठिन हो गयी है या सुरक्षा पैच बंद हो गये, पर SQL को साझा भाषा के रूप में कम ही छोड़ती है।
डेटाबेस मानक और convections एक सामान्य बेसलाइन बनाते हैं: SQL डायलैक्टस एक-दूसरे से अलग हैं, पर वे ज्यादातर वेब फ्रेमवर्क्स से ज़्यादा समान होते हैं। इससे डेटाबेस को स्थिर रखते हुए एप्लिकेशन लेयर को विकसित करना आसान होता है।
प्रायोगिक प्रभाव सरल है: जब टीमें एप्लिकेशन री-राइट की योजना बनाती हैं, तो वे अक्सर मौजूदा डेटाबेस कौशल, क्वेरी पैटर्न और ऑपरेशनल प्रैक्टिसेज़ रख सकती हैं—इसलिए डेटाबेस कई पीढ़ियों के कोड से बाहरखड़ा फाउंडेशन बन जाता है।
अधिकतर टीमें उसी डेटाबेस के साथ इसलिए नहीं रहतीं क्योंकि उन्हें वह बहुत पसंद है। वे इसलिए रहती हैं क्योंकि उन्होंने उसके आसपास काम करने की आदतें बना ली हैं—और उन आदतों को हासिल करना कठिन होता है।
एक बार डेटाबेस प्रोडक्शन में आ जाए, तो वह कम्पनी की "ऑलवेज-ऑन" मशीनरी का हिस्सा बन जाता है। यह वही चीज है जिसके लिए लोग रात 2 बजे पेज करते हैं, वही चीज जिसकी ऑडिट माँगती है, और वही चीज जिससे हर नया सर्विस अंततः बात करनी चाहती है।
एक या दो साल के बाद, टीमों के पास आमतौर पर एक भरोसेमंद रिद्म होता है:
डेटाबेस को बदलना मतलब उन सबको असली लोड के साथ फिर से सीखना है, असली ग्राहक अपेक्षाओं के साथ।
डेटाबेस शायद ही "सेट एंड भूल" होते हैं। समय के साथ, टीम उनके लिए विश्वसनीयता ज्ञान का कैटलॉग बनाती है:
यह ज्ञान अक्सर डैशबोर्ड्स, स्क्रिप्ट्स और लोगों के सिर में रहता है—किसी एक दस्तावेज़ में नहीं। एप्लिकेशन कोड का री-राइट व्यवहार को संरक्षित कर सकता है जबकि डेटाबेस सर्व करता रहता है। डेटाबेस का प्रतिस्थापन आपको व्यवहार, प्रदर्शन और विश्वसनीयता एक साथ फिर से बनाने पर मजबूर करता है।
सुरक्षा और एक्सेस नियंत्रण केंद्रीय और लंबे समय तक चलने वाले होते हैं। रोल्स, परमिशन्स, ऑडिट लॉग्स, सीक्रेट्स रोटेशन, एन्क्रिप्शन सेटिंग्स, और "कौन क्या पढ़ सकता है" अक्सर कम्प्लायंस आवश्यकताओं और आंतरिक नीतियों से मेल खाते हैं।
डेटाबेस बदलना मतलब एक्सेस मॉडल फिर से बनाना, नियंत्रणों को पुनः मान्य करना और व्यापार को साबित करना कि संवेदनशील डेटा अभी भी सुरक्षित है।
ऑपरेशनल परिपक्वता डेटाबेस को जगह पर रखती है क्योंकि यह जोखिम को घटाती है। भले ही नया डेटाबेस बेहतर फीचर्स का वादा करे, पुराना डेटाबेस के पास एक शक्तिशाली चीज़ होती है: यह ऊपर रहने, recoverable रहने और गड़बड़ी होने पर समझ में आने का इतिहास रखता है।
एप्लिकेशन को नया फ्रेमवर्क या साफ़ आर्किटेक्चर देकर बदला जा सकता है। कम्प्लायंस दायित्व पर रिकॉर्ड्स जुड़े होते हैं—क्या हुआ, कब हुआ, किसने स्वीकृति दी, और उस समय ग्राहक ने क्या देखा। इसलिए डेटाबेस अक्सर री-राइट में अचल वस्तु बन जाता है।
कई उद्योगों में इनवॉइस, सहमति रिकॉर्ड, वित्तीय इवेंट्स, सपोर्ट इंटरैक्शन्स और एक्सेस लॉग्स के लिए न्यूनतम रिटेंशन पीरियड्स होते हैं। ऑडिटर आमतौर पर "हमने ऐप री-राइट कर दी" को इतिहास खोने का कारण नहीं मानते।
यहां तक कि अगर आपकी टीम किसी लेगेसी टेबल का रोज़मर्रा उपयोग नहीं करती, तब भी आपसे उसे मांगा जा सकता है और आपको यह बताना होगा कि इसे कैसे बनाया गया था।
चार्जबैक्स, रिफंड्स, डिलीवरी विवाद और कॉन्ट्रैक्ट प्रश्न ऐतिहासिक स्नैपशॉट्स पर निर्भर करते हैं: उस समय की कीमत, उपयोग किया गया पता, स्वीकार किए गए नियम, या किसी विशेष मिनट पर स्थिति।
जब डेटाबेस उन तथ्यों का अधिकारिक स्रोत होता है, तो इसे बदलना केवल तकनीकी प्रोजेक्ट नहीं होता—यह सबूत को बदलने का जोखिम उठाता है। इसलिए टीमें मौजूदा डेटाबेस को ही रखते हैं और उसके चारों ओर नए सर्विस बनाती हैं, बजाय इसके कि वे "माइग्रेट करें और आशा करें कि मेल खाएगा"।
कुछ रिकॉर्ड्स को डिलीट नहीं किया जा सकता; कुछ को ऐसे बदला नहीं जा सकता जो ट्रेसबिलिटी तोड़ दे। यदि आप denormalize करते हैं, फ़ील्ड्स को मर्ज या ड्रॉप करते हैं, तो आप ऑडिट ट्रेल को पुनर्निर्मित करने की क्षमता खो सकते हैं।
ये तनाव खासकर तब दिखाई देता है जब प्राइवेसी आवश्यकताएँ रिटेंशन के साथ टकराती हैं: आपको कभी-कभी सेलेक्टिव रेडैक्शन या यूज़र-पर्सोनोनिमाइज़ेशन की ज़रूरत होती है जबकि ट्रांज़ैक्शन हिस्ट्री को बनाए रखना पड़ता है। ये प्रतिबंध आमतौर पर डेटा के सबसे नजदीक रहते हैं।
डेटा क्लासिफिकेशन (PII, वित्तीय, स्वास्थ्य, इंटर्नल-ओनली) और गवर्नेंस नीतियाँ आमतौर पर स्थिर रहती हैं जब उत्पाद विकसित होते हैं। एक्सेस कंट्रोल, रिपोर्टिंग परिभाषाएँ, और "सिंगल सोर्स ऑफ ट्रूथ" निर्णय अक्सर डेटाबेस स्तर पर लागू किए जाते हैं क्योंकि इसे कई टूल्स उपयोग करते हैं: BI डैशबोर्ड, फाइनेंस एक्सपोर्ट, रेगुलेटर रिपोर्ट्स और इन्सिडेंट जांच।
अगर आप री-राइट की योजना बना रहे हैं, तो कम्प्लायंस रिपोर्टिंग को प्राथमिक आवश्यकता मानें: आवश्यक रिपोर्ट्स, रिटेंशन शेड्यूल और ऑडिट फ़ील्ड्स का इन्वेंटरी बनाएं पहले कि आप स्कीमा में छेड़छाड़ करें। एक साधारण चेकलिस्ट मदद कर सकती है (देखें /blog/database-migration-checklist)।
ज़्यादातर "अस्थायी" डेटाबेस चुनाव अनजाने नहीं किए जाते—वे दबाव में किये जाते हैं: लॉन्च डेडलाइन, तत्काल क्लाइंट रिक्वेस्ट, नई रेगुलेशन, या एक गंदा इंपोर्ट। आश्चर्यजनक बात यह है कि वे विकल्प कितनी कम बार उलटाए जाते हैं।
एप्लिकेशन कोड जल्दी रिफैक्टर किया जा सकता है, पर डेटाबेस को पुराने और नए कंज्यूमर्स को एक साथ सेवा देते रहना होता है। लेगेसी टेबल्स और कॉलम्स बने रहते हैं क्योंकि कुछ उन पर निर्भर रहता है:
भले ही आप किसी फ़ील्ड का नाम बदलें, आप अक्सर पुराने वाला भी रखते हैं। एक सामान्य पैटर्न है नया कॉलम जोड़ना (उदा., customer_phone_e164) जबकि phone को अनिश्चित काल के लिए रखना क्योंकि कोई नाइटली एक्सपोर्ट अभी भी उसका उपयोग करता है।
वर्कअराउंड्स स्प्रेडशीट्स, डैशबोर्ड और CSV एक्सपोर्ट में एम्बेड हो जाते हैं—ऐसे स्थान जो शायद ही प्रोडक्शन कोड की तरह ट्रीट किए जाते हैं। कोई राजस्व रिपोर्ट बनाता है जो एक डिप्रीकेटेड टेबल को "फाइनेंस माइग्रेट होने तक" जॉइन करती है। फिर फाइनेंस की क्वार्टरली प्रक्रिया उसी पर निर्भर हो जाती है, और उस टेबल को हटाना कारोबारी जोखिम बन जाता है।
इसीलिए डिप्रिकेटेड टेबल्स वर्षों तक जीवित रह सकती हैं: डेटाबेस सिर्फ ऐप को सर्व नहीं कर रहा होता; यह संगठन की आदतों को सर्व कर रहा होता है।
एक फ़ील्ड जो त्वरित फिक्स के रूप में जोड़ा गया—promo_code_notes, legacy_status, manual_override_reason—अक्सर वर्कफ़्लो में निर्णय बिंदु बन जाता है। जब लोग इसे परिणामों को समझाने के लिए उपयोग करने लगते हैं ("हमने यह ऑर्डर इसलिए अप्रूव किया क्योंकि..."), तब यह गैर-ऐच्छिक बन जाता है।
जब टीमें माइग्रेशन पर भरोसा नहीं करतीं, तो वे "शैडो" कॉपियाँ रखती हैं: डुप्लिकेटेड कस्टमर नाम, कैश्ड टोटल्स, या फॉलबैक फ़्लैग्स। ये अतिरिक्त कॉलम हल्के लगते हैं, पर वे प्रतियोगी सिंगल सोर्स ऑफ ट्रूथ बनाते हैं—और नए निर्भरताएँ बनाते हैं।
यदि आप इस जाल में फँसना नहीं चाहते, तो स्कीमा बदलावों को प्रोडक्ट बदलाव की तरह ट्रीट करें: उद्देश्य को डॉक्यूमेंट करें, डिप्रिकेशन डेट्स मार्क करें, और हटाने से पहले कंज्यूमर्स को ट्रैक करें। एक व्यावहारिक चेकलिस्ट के लिए देखें /blog/schema-evolution-checklist.
एक ऐसा डेटाबेस जो कई एप्लिकेशन पीढ़ियों से बचता है, उसे आंतरिक कार्यान्वयन विवरण की तरह नहीं बल्कि साझा इन्फ्रास्ट्रक्चर की तरह माना जाना चाहिए। लक्ष्य हर भविष्य फ़ीचर की भविष्यवाणी करना नहीं है—बल्कि परिवर्तन को सुरक्षित, क्रमिक और उलटने योग्य बनाना है।
एप्लिकेशन कोड री-राइट हो सकता है, पर डेटा कॉन्ट्रैक्ट्स पुनर्विनियोजित करना कठिन होते हैं। तालिकाओं, कॉलम्स और की रिलेशनशिप्स को एक API की तरह सोचें जिस पर अन्य सिस्टम (और भविष्य की टीमें) निर्भर करेंगी।
प्राथमिकता दें ऐडिटिव परिवर्तन:
भविष्य की री-राइट्स अक्सर इसलिए फेल होती हैं क्योंकि डेटा अस्पष्ट होता है।
स्पष्ट, सुसंगत नाम उपयोग करें जो इरादा बताए (उदा., billing_address_id बनाम addr2)। जहाँ संभव हो नियमों को कन्स्ट्रेंट्स से एन्कोड करें: प्राइमरी कीज़, फॉरेन कीज़, NOT NULL, यूनिक और चेक कन्स्ट्रेंट्स।
स्कीमा के पास हल्का डॉक्यूमेंटेशन जोड़ें—टेबल/कॉलम कमेंट्स या आंतरिक हैंडबुक से लिंक किया हुआ छोटा लिविंग डॉक। "क्यों" उतना ही मायने रखता है जितना "क्या"।
हर बदलाव के लिए आगे और पीछे का रास्ता होना चाहिए।
एक व्यावहारिक तरीका यह है कि अक्सर एप्लिकेशन इटरेशन्स के दौरान डेटाबेस परिवर्तनों को सुरक्षित रखने के लिए अपनी delivery workflow में “planning mode” और rollback discipline शामिल करें। उदाहरण के लिए, जब टीमें Koder.ai पर आंतरिक टूल्स या नए ऐप वर्ज़न्स बनाती हैं, वे चैट के माध्यम से iterate कर सकती हैं जबकि स्कीमा को स्थिर कॉन्ट्रैक्ट की तरह ट्रीट करती हैं—स्नैपशॉट्स और रोलबैक-स्टाइल प्रैक्टिसेज़ का उपयोग करके आकस्मिक बदलावों के ब्लास्ट रेडियस को घटाने के लिए।
अगर आप अपना डेटाबेस स्थिर कॉन्ट्रैक्ट और सुरक्षित विकास के साथ डिजाइन करते हैं, तो एप्लिकेशन री-राइट्स सामान्य घटना बन जाती हैं—जो हर बार डेटा रेस्क्यू मिशन नहीं बनती।
डेटाबेस बदलना दुर्लभ है, पर असंभव नहीं। जो टीमें इसे सफलतापूर्वक करती हैं वे "बहादुर" नहीं होतीं—वे सालों पहले तैयारी करती हैं: डेटा पोर्टेबल बनाना, निर्भरताओं को दृश्य बनाना, और एप्लिकेशन को एक इंजन से सख्ती से बाँधने से रोकना।
एक्सपोर्ट्स को एक-बार की स्क्रिप्ट मानने की बजाय प्रथम श्रेणी क्षमता की तरह ट्रीट करें।
टाइट कपलिंग वही चीज़ है जो माइग्रेशन को री-राइट में बदल देती है।
संतुलित अप्रोच की कोशिश करें:
यदि आप जल्दी नया सर्विस बना रहे हैं (उदा., React एडमिन ऐप + Go बैकएंड और PostgreSQL), तो एक ऐसा स्टैक चुनना मददगार है जो पोर्टेबिलिटी और ऑपरेशनल स्पष्टता को डिफ़ॉल्ट बनाए। Koder.ai उन व्यापक अपनाए गए प्रिमिटिव्स पर निर्भर करता है, और यह सोर्स कोड एक्सपोर्ट को सपोर्ट करता है—जब आप अपना एप्लिकेशन लेयर रिप्लेस करने योग्य रखना चाहते हैं बिना अपने डेटा मॉडल को किसी एक-ऑफ टूल में लॉक किए।
डेटाबेस अक्सर मुख्य ऐप से ज्यादा कुछ और पावर करते हैं: रिपोर्ट्स, स्प्रेडशीट्स, शेड्यूल्ड ETL जॉब्स, थर्ड-पार्टी इंटीग्रेशन्स, और ऑडिट पाइपलाइन।
एक लिविंग इन्वेंटरी रखें: क्या पढ़ता/लिखता है, कितनी बार, और अगर यह टूटे तो क्या होगा। /docs में एक साधारण पेज भी मालिकों और संपर्क बिंदुओं के साथ बुरी आश्चर्यों को रोकता है।
सामान्य संकेत: लाइसेंसिंग या होस्टिंग प्रतिबंध, अनसुलझे विश्वसनीयता मुद्दे, मिसिंग कम्प्लायंस फीचर्स, या ऐसे स्केल लिमिट्स जो चरम वर्कअराउंड्स मजबूर करें।
मुख्य जोखिम: डेटा लॉस, सूक्षम अर्थ परिवर्तनों, डाउनटाइम, और रिपोर्टिंग ड्रिफ्ट।
एक सुरक्षित तरीका आम तौर पर पैरेलल रन होता है: डेटा को निरंतर माइग्रेट करें, परिणामों को मान्य करें (काउंट्स, चेकसम, बिजनेस मेट्रिक्स), धीरे-धीरे ट्रैफ़िक शिफ्ट करें, और तब तक रोलबैक पाथ रखें जब तक आत्मविश्वास उच्च न हो।
क्योंकि डेटाबेस व्यापार की ऐतिहासिक सच्चाई (कस्टमर, ऑर्डर, इनवॉइस, ऑडिट ट्रेल) रखता है। कोड को पुनः तैनात या फिर से लिखा जा सकता है; खोई या भ्रष्ट हुई हिस्ट्री को पुनः बनाना मुश्किल होता है और इससे वित्तीय, कानूनी और भरोसे का नुकसान हो सकता है।
डेटा परिवर्तन साझा और स्थायी होते हैं.
एक ही डेटाबेस अक्सर एक साझा सिंगल सोर्स ऑफ ट्रूथ बन जाता है, जो सेवाओं और प्रक्रियाओं के कई हिस्सों को परोसा जाता है:
भले ही आप ऐप को री-राइट करें, ये सभी उपभोक्ता स्थिर तालिकाओं, IDs और अर्थों पर निर्भर रहते हैं।
अक्सर नहीं। अधिकांश "माइग्रेशन" इस तरह चरणबद्ध होते हैं कि डेटाबेस कॉन्ट्रैक्ट स्थिर रहे जबकि एप्लिकेशन घटक बदलते हैं.
सामान्य तरीका:
सुरक्षित परिवर्तन सामान्यतः ऐडिटिव होते हैं:
यह पुरानी और नई कोड को साथ-साथ चलने देता है जब आप ट्रांज़िशन कर रहे होते हैं।
अस्पष्टता को लंबे समय तक बनाए रखने की बजाय अर्थ को स्पष्ट रखें.
व्यवहारिक कदम:
billing_address_id).NOT NULL, unique, check)।असामान्य ("weird") पंक्तियों की उम्मीद रखें.
माइग्रेट करने से पहले योजना बनाएं कि कैसे संभालेंगे:
प्रोडक्शन-जैसे डेटा पर माइग्रेशन का टेस्ट करें और केवल ट्रांसफॉर्म लॉजिक नहीं, वेरिफिकेशन स्टेप्स भी शामिल करें।
कम्प्लायंस रिकॉर्ड्स के साथ जुड़ा होता है, UI के साथ नहीं.
आपको संरक्षित और पुन:उत्पन्न करने की ज़रूरत पड़ सकती है:
फ़ील्ड्स को फिर से आकार देना या हटाना ट्रेसबिलिटी, रिपोर्टिंग परिभाषाएँ या ऑडिटेबिलिटी तोड़ सकता है—यहाँ तक कि अगर ऐप बदल गया हो तब भी।
क्योंकि संगतता छिपे हुए निर्भरता बनाती है:
डिप्रिकेशन को प्रोडक्ट चेंज की तरह ट्रीट करें: इरादे को डॉक्यूमेंट करें, कंज्यूमर्स को ट्रैक करें, और रिटायरमेंट प्लान सेट करें।
व्यवहारिक चेकलिस्ट:
यहां तक कि बड़े री-राइट्स भी रूटिन बन सकते हैं, न कि जोखिम भरे "डेटा रेस्क्यू" प्रोजेक्ट।