जैसे-जैसे सिस्टम की जटिलता बढ़ती है, नीचे की डेटा संरचनाओं की स्थिरता संचालन विश्वसनीयता का आधार बन जाती है। इंजीनियरिंग टीमों के सामने सबसे लंबे समय तक रहने वाली चुनौतियों में से एक स्कीमा ड्रिफ्ट है। यह घटना तब होती है जब डेटाबेस स्कीमा का अपेक्षित डिज़ाइन से विचलन होता है, जिससे असंगतियाँ, टूटे हुए प्रश्न और अप्रत्याशित एप्लिकेशन व्यवहार होता है। जबकि इसे अक्सर डेटाबेस प्रशासन के मुद्दे के रूप में लिया जाता है, लेकिन मूल कारण अक्सर एंटिटी रिलेशनशिप डायग्राम (ERD) के आर्किटेक्चर और शुरुआती नियंत्रण में होता है।
एक अच्छी तरह से बनाए गए ERD केवल संबंधों को दृश्यमान बनाने से अधिक करता है; यह एप्लिकेशन लॉजिक और डेटा स्टोरेज लेयर के बीच एक संविदा के रूप में कार्य करता है। स्केलेबल वातावरण में जहां कई सेवाएं साझा डेटा के साथ बातचीत करती हैं, इस संविदा को कठोर लेकिन विकास को स्वीकार करने के लिए पर्याप्त लचीला होना चाहिए। यह गाइड डेटा मॉडल को स्थिर रखने और उत्पादन को प्रभावित करने से पहले स्कीमा ड्रिफ्ट को रोकने वाले आर्किटेक्चरल पैटर्न और विधियों का अध्ययन करता है।
📉 वितरित वातावरणों में स्कीमा ड्रिफ्ट को समझना
स्कीमा ड्रिफ्ट केवल एक टेबल को अपडेट करना भूल जाने के मामले में नहीं है। यह एक प्रणालीगत समस्या है जहां समय के साथ डेटा मॉडल के भौतिक कार्यान्वयन का उसके तार्किक परिभाषा से विचलन होता है। मोनोलिथिक सिस्टम में, इसका परिणाम कुछ भूले गए कॉलम के रूप में दिख सकता है। वितरित, माइक्रोसर्विस आर्किटेक्चर में, इसके परिणामस्वरूप रेस कंडीशन हो सकती है जहां सेवा A डेटा को एक ऐसे फॉर्मेट में लिखती है जिसे सेवा B पढ़ नहीं सकती है।
अनियंत्रित ड्रिफ्ट के परिणाम शामिल हैं:
- डेटा अखंडता का नुकसान:प्रतिबंधों को बायपास किया जाता है, जिससे अमान्य अवस्थाएं अनुमत होती हैं।
- तकनीकी ऋण में वृद्धि:डेवलपर्स फीचर बनाने के बजाय डेटा समस्याओं के निराकरण में अधिक समय बिताते हैं।
- सेवा विफलताएं:एपीआई तब विफल हो जाती हैं जब विशिष्ट फील्ड प्रकार या उपस्थिति की अपेक्षा की जाती है।
- माइग्रेशन की जटिलता:अंतर बढ़ने के साथ पीछा करना मुश्किल हो जाता है।
इसकी रोकथाम के लिए ERD के लिए एक आर्किटेक्चरल दृष्टिकोण की आवश्यकता होती है जो लचीलेपन को दबाए बिना स्थिरता को बनाए रखे। इसमें बदलाव के नियम तय करना, डेटा मॉडल को संस्करण देना और डायग्राम के आसपास शासन स्थापित करना शामिल है।
🛡️ आधार: ERD एक सत्य का स्रोत के रूप में
ड्रिफ्ट को रोकने का पहला चरण एंटिटी रिलेशनशिप डायग्राम को एक स्थिर ड्राइंग से एक जीवंत दस्तावेज में बदलना है जो कार्यान्वयन को प्रभावित करता है। जब ERD को द्वितीयक कलाकृति के रूप में लिया जाता है, तो ड्रिफ्ट अनिवार्य हो जाता है। जब इसे मुख्य सत्य का स्रोत माना जाता है, तो आर्किटेक्चर स्थिरता का समर्थन करता है।
1. तार्किक बनाम भौतिक अलगाव
लचीलेपन बनाए रखते हुए स्थिरता सुनिश्चित करने के लिए, तार्किक डेटा मॉडल को भौतिक कार्यान्वयन से अलग करें। तार्किक ERD को तकनीकी प्रतिबंधों के बिना व्यावसायिक एंटिटी और उनके संबंधों का वर्णन करना चाहिए। भौतिक ERD इंडेक्सिंग, पार्टीशनिंग और विशिष्ट स्टोरेज प्रकारों के प्रबंधन को संभालता है।
इस अलगाव के कारण व्यावसायिक तर्क के विकास के लिए तुरंत भौतिक परिवर्तन के बल नहीं डाले जाते हैं। यह एक बफर क्षेत्र बनाता है जहां परिवर्तनों को भौतिक स्तर को प्रभावित करने से पहले व्यावसायिक आवश्यकताओं के अनुसार मूल्यांकन किया जा सकता है।
2. मानक डेटा मॉडल
स्केलेबल सिस्टम में, कई सेवाओं को अक्सर एक ही डेटा को समझने की आवश्यकता होती है। एक मानक डेटा मॉडल स्थापित करने से यह सुनिश्चित होता है कि सभी सेवाएं एक ही परिभाषाओं को संदर्भित करें। ERD इन मानक एंटिटी को परिभाषित करता है।
- एकमात्र सत्य का स्रोत:ERD महत्वपूर्ण एंटिटी जैसे उपयोगकर्ता, ऑर्डर या इन्वेंटरी के लिए ठीक स्कीमा को परिभाषित करता है।
- सेवा संविदाएं:सेवाएं ERD परिभाषा के आधार पर डेटा का उपभोग करती हैं, न कि अनियमित प्रश्नों के आधार पर।
- मानकीकृत नामकरण:ERD में परिभाषित नामकरण प्रणाली विभिन्न डेटाबेस इंस्टेंस के बीच अस्पष्टता को रोकती है।
🧩 ERD स्थिरता के लिए आर्किटेक्चरल पैटर्न
विभिन्न सिस्टम आर्किटेक्चर के लिए अलग-अलग ERD रणनीतियां आवश्यक होती हैं। निम्नलिखित पैटर्न सिस्टम के स्केल होने पर संगतता बनाए रखने में मदद करते हैं।
1. साझा डेटाबेस पैटर्न
कुछ मोनोलिथिक या तंतु जुड़े सिस्टम में, एक साझा डेटाबेस का उपयोग किया जाता है। यहाँ, एरडी को बहुत सख्त होना चाहिए। एरडी में परिवर्तन करने के लिए उस डेटाबेस को एक्सेस करने वाले सभी मॉड्यूलों के बीच समन्वय की आवश्यकता होती है।
- केंद्रीकृत स्कीमा प्रबंधन: एक ही टीम एरडी अपडेट्स के मालिक है।
- कठोर पहुँच नियंत्रण: केवल अधिकृत स्क्रिप्ट्स ही स्कीमा को बदल सकती हैं।
- निर्भरता ट्रैकिंग: एरडी को तालिकाओं के बीच निर्भरताओं को स्पष्ट रूप से मैप करना चाहिए ताकि परिवर्तन से पहले प्रभाव की पहचान की जा सके।
2. सेवा प्रति डेटाबेस पैटर्न
माइक्रोसर्विस आर्किटेक्चर में, प्रत्येक सेवा अपने डेटा के मालिक होती है। इससे सीधे कपलिंग कम होती है, लेकिन सेवाओं के बीच असंगत डेटा परिभाषाओं के जोखिम को बढ़ाता है। यहाँ एरडी आर्किटेक्चर प्रत्येक सेवा के आंतरिक भंडारण के बजाय सेवाओं के बीच इंटरफेस पर ध्यान केंद्रित करता है।
- आंतरिक लचीलापन: प्रत्येक सेवा अपने आंतरिक स्कीमा को विकसित कर सकती है, बशर्ते बाहरी इंटरफेस स्थिर रहे।
- बाहरी अनुबंध: एरडी साझा अनुबंधों को परिभाषित करता है। यदि सेवा A को सेवा B से डेटा की आवश्यकता है, तो एरडी अपेक्षित संरचना को परिभाषित करता है।
- घटना स्रोत: एरडी उन घटनाओं को परिभाषित कर सकता है जो डेटा ले जाती हैं, जिससे अपरिवर्तनीयता और ट्रेसेबिलिटी सुनिश्चित होती है।
3. क्षेत्र-ड्राइवन डिज़ाइन (DDD) दृष्टिकोण
क्षेत्र-ड्राइवन डिज़ाइन व्यवसाय क्षेत्रों के साथ डेटाबेस स्कीमा को समायोजित करता है। एरडी को सीमित संदर्भों के अनुसार तोड़ा जाता है। इससे बचा जाता है कि असंबंधित एंटिटीज को एक ही स्कीमा में बाध्य किया जाए, जिसे ‘गॉड टेबल’ समस्या कहा जाता है।
- संदर्भ मैपिंग: एरडी सीमित संदर्भों के बीच संबंधों को मैप करता है।
- सामान्य भाषा: एरडी में एंटिटी के नाम व्यवसाय की भाषा के अनुरूप होते हैं।
- एन्कैप्सुलेशन: आंतरिक एंटिटीज को छिपाया जाता है; केवल डोमेन सीमा को ही उजागर किया जाता है।
🔄 स्कीमा विकास के लिए संस्करण नियंत्रण रणनीतियाँ
परिवर्तन अपरिहार्य है। लक्ष्य उसे ऐसे प्रबंधित करना है कि मौजूदा उपभोक्ताओं को नुकसान न पहुँचे। एरडी आर्किटेक्चर के भीतर स्कीमा के संस्करण नियंत्रण क्रांतिक है।
1. स्कीमा के लिए अर्थपूर्ण संस्करण नियंत्रण
जैसे सॉफ्टवेयर कोड में अर्थपूर्ण संस्करण नियंत्रण का उपयोग किया जाता है, वैसे ही डेटा स्कीमा में भी किया जाना चाहिए। एक स्कीमा संस्करण को मेजर.माइनर.पैच के रूप में निरूपित किया जा सकता है।
- मेजर: तोड़ने वाले परिवर्तन (उदाहरण के लिए, कॉलम हटाना, प्रकार बदलना)।
- लघु: पीछे की ओर संगति वाले जोड़ (उदाहरण के लिए, एक नल-संभव कॉलम जोड़ना)।
- पैच: ऐसे आंतरिक ठीक करने या अनुकूलन जो एपीआई को प्रभावित नहीं करते।
2. पीछे की ओर संगति के नियम
विचलन को रोकने के लिए, स्कीमा के विकास के बारे में सख्त नियमों का पालन करें। निम्नलिखित तालिका सुरक्षित बदलावों बनाम असुरक्षित बदलावों को चिह्नित करती है।
| क्रिया | संगति | आवश्यकता |
|---|---|---|
| नया कॉलम जोड़ें | पीछे की ओर संगत | शुरुआत में NULL की अनुमति देनी चाहिए |
| नया तालिका जोड़ें | पीछे की ओर संगत | शुरुआत में कोई विदेशी कुंजी निर्भरता न हो |
| कॉलम हटाएं | टूटने वाला बदलाव | पहले अप्रचलित करें, फिर बाद में हटाएं |
| डेटा प्रकार बदलें | टूटने वाला बदलाव | पूर्ण माइग्रेशन योजना की आवश्यकता होती है |
| विदेशी कुंजी जोड़ें | शर्ती | यह सुनिश्चित करें कि मौजूदा डेटा सीमा को पूरा करता है |
3. डुअल लेखन पैटर्न
जब स्कीमा बदलाव की आवश्यकता हो, तो तुरंत कटओवर से बचें। डुअल लेखन रणनीति को लागू करें जहां डेटा पुरानी और नई संरचना दोनों में लिखा जाता है। समय के साथ, ट्रैफिक को नई संरचना में स्थानांतरित किया जाता है। इस संक्रमण के दौरान एरडी में दोनों संस्करणों को दस्तावेज़ीकृत करना चाहिए।
- पठन मार्ग: स्थिर स्कीमा से पठन जारी रखें।
- लेखन मार्ग: दोनों स्कीमा में एक साथ लेखन करें।
- प्रमाणीकरण: दोनों स्कीमा के बीच डेटा सुसंगतता का निरीक्षण करें।
- स्थानांतरण: एक बार प्रमाणित करने के बाद, पुराने स्कीमा में लेखन बंद कर दें।
⚙️ माइग्रेशन प्रबंधन और शासन
संस्करण प्रबंधन के साथ भी, माइग्रेशन आवश्यक हैं। आर्किटेक्चर को सुरक्षित, उलटा जाने योग्य और स्वचालित माइग्रेशन का समर्थन करना चाहिए।
1. कोड के रूप में माइग्रेशन स्क्रिप्ट
माइग्रेशन को एप्लिकेशन कोड के साथ संस्करणित किया जाना चाहिए। ईआरडी इन स्क्रिप्ट्स के लिए लक्ष्य स्थिति के रूप में कार्य करता है। प्रत्येक माइग्रेशन फ़ाइल को उस विशिष्ट ईआरडी संस्करण को संदर्भित करना चाहिए जिसे वह लागू करती है।
- आइडेम्पोटेंसी: स्क्रिप्ट्स को बार-बार चलाने में सुरक्षित होना चाहिए।
- वापसी क्षमता: प्रत्येक अपग्रेड के लिए एक संबंधित डाउनग्रेड स्क्रिप्ट होनी चाहिए।
- परमाणुता: जहां संभव हो, बदलाव लेनदेन के रूप में हों ताकि आंशिक अपडेट से बचा जा सके।
2. स्कीमा रजिस्ट्री
वातावरणों के बीच ईआरडी की स्थिति को ट्रैक करने के लिए एक स्कीमा रजिस्ट्री कार्यान्वित करें। इससे यह सुनिश्चित होता है कि विकास, स्टेजिंग और उत्पादन वातावरण समान हों।
- वातावरण समानता: डेव और प्रोड के बीच विचलन को रोकता है।
- अनुमोदन कार्य प्रवाह: स्कीमा में परिवर्तनों को प्रमोशन से पहले समीक्षा की आवश्यकता होती है।
- प्रमाणीकरण: स्वचालित जांच सुनिश्चित करती है कि निर्मित स्कीमा पंजीकृत ईआरडी के अनुरूप है।
3. कोड के रूप में दस्तावेज़ीकरण
दस्तावेज़ीकरण को ईआरडी से ही उत्पन्न किया जाना चाहिए। इससे यह सुनिश्चित होता है कि आरेख और पाठ विवरण समायोजित रहते हैं। हाथ से लिखे दस्तावेज़ अक्सर तेजी से अद्यतन नहीं होते।
- स्वचालित उत्पादन: उपकरण ईआरडी फ़ाइल से दस्तावेज़ीकरण उत्पन्न कर सकते हैं।
- जीवित दस्तावेज़: दस्तावेज़ीकरण अपडेट कोड समीक्षा प्रक्रिया का हिस्सा होते हैं।
- संदर्भ संकेत: व्यवसाय तर्क संकेतों को सीधे ईआरडी मेटाडेटा में शामिल करें।
📝 स्वचालन और CI/CD एकीकरण
मानव त्रुटि स्कीमा ड्रिफ्ट का मुख्य कारण है। स्वचालन डेप्लॉयमेंट पाइपलाइन के दौरान नियमों को लागू करके इस जोखिम को कम करता है।
1. प्री-कॉमिट हुक्स
स्कीमा बदलावों को रिपोजिटरी में कॉमिट करने से पहले उनकी पुष्टि करने वाले हुक्स कार्यान्वित करें। इन हुक्स का उपयोग वर्तमान ERD परिभाषा के खिलाफ तोड़ने वाले बदलावों की जांच के लिए किया जाता है।
- लिंटिंग: नामकरण परंपराओं और संरचना नियमों को लागू करें।
- सत्यापन: सुनिश्चित करें कि नए प्रतिबंध मौजूदा डेटा के साथ टकराव न करें।
- समीक्षा: उच्च जोखिम वाले बदलावों के लिए मैन्युअल अनुमोदन आवश्यक है।
2. निरंतर एकीकरण जांचें
CI प्रक्रिया के दौरान एक परीक्षण डेटाबेस के खिलाफ स्कीमा सत्यापन चलाएं। इससे डेप्लॉयमेंट से पहले समस्याओं का पता चल जाता है।
- सैंडबॉक्स पर्यावरण: माइग्रेशन का परीक्षण करने के लिए एक अस्थायी पर्यावरण में डेप्लॉय करें।
- एकीकरण परीक्षण: सुनिश्चित करने के लिए स्कीमा पर निर्भर जांचें चलाएं कि कार्यक्षमता सुनिश्चित हो।
- प्रदर्शन जांचें: सुनिश्चित करें कि नए इंडेक्स लेखन प्रदर्शन को खराब न करें।
3. डेटा के लिए ब्लू-ग्रीन डेप्लॉयमेंट
एप्लिकेशन डेप्लॉयमेंट के समान, डेटा के लिए ब्लू-ग्रीन रणनीतियों का उपयोग करें। नई संस्करण स्थिर होने तक स्कीमा के दो संस्करणों को समानांतर में बनाए रखें।
- शून्य डाउनटाइम: उपयोगकर्ता स्कीमा बदलावों से प्रभावित नहीं होते हैं।
- तत्काल रोलबैक: यदि समस्या उत्पन्न होती है, तो पिछले स्कीमा संस्करण पर वापस जाएं।
- डेटा समन्वय: संक्रमण के दौरान दोनों संस्करणों के बीच डेटा संगत हो इसकी गारंटी दें।
🚨 बचने के लिए सामान्य त्रुटियां
एक मजबूत आर्किटेक्चर के साथ भी, टीमें अक्सर ऐसे जाल में फंस जाती हैं जिनसे ड्रिफ्ट फिर से आ जाती है। लंबे समय तक स्थिरता के लिए इन त्रुटियों के प्रति जागरूकता आवश्यक है।
1. अप्रत्यक्ष निर्भरताएं
कोड अक्सर उन डेटा संरचनाओं पर निर्भर होता है जो ERD में स्पष्ट रूप से परिभाषित नहीं होती हैं। कड़े कॉलम नाम या डेटा उपलब्धता के बारे में मान्यताएं चुप्पी से विफलता का कारण बनती हैं।
- स्पष्ट प्रकार निर्दिष्ट करना: सभी डेटा एक्सेस लेयर में मजबूत प्रकार निर्दिष्ट करें।
- इंटरफेस अनुबंध: डेटा एक्सेस के लिए स्पष्ट इंटरफेस परिभाषित करें।
- रिफैक्टरिंग: अप्रत्यक्ष मान्यताओं के लिए कोड का नियमित रूप से ऑडिट करें।
2. डेटा गुणवत्ता को नजरअंदाज करना
एक स्कीमा परफेक्ट हो सकता है, लेकिन यदि इसमें प्रवेश कर रहे डेटा गंदे हैं, तो सिस्टम विफल हो जाता है। ईआरडी में डेटा गुणवत्ता को बनाए रखने वाले प्रतिबंध शामिल होने चाहिए।
- चेक प्रतिबंध: डेटाबेस स्तर पर मानों की पुष्टि करें।
- यूनिक प्रतिबंध: डुप्लीकेट प्रविष्टियों को रोकें।
- नॉट नल प्रतिबंध: सुनिश्चित करें कि आवश्यक फील्ड हमेशा भरे जाएँ।
3. अत्यधिक इंडेक्सिंग
पढ़ने के प्रदर्शन को हल करने के लिए इंडेक्स जोड़ने से लिखने की गति कम हो जाती है। इससे लिखने के मार्ग को बाधित करने वाले स्कीमा परिवर्तन हो सकते हैं।
- पहले मापें: इंडेक्स जोड़ने से पहले प्रश्न प्रदर्शन को मॉनिटर करें।
- नियमित रूप से समीक्षा करें: अप्रयुक्त इंडेक्स हटाएं ताकि ओवरहेड कम हो।
- संतुलन: पढ़ने और लिखने के प्रदर्शन के बीच सही संतुलन ढूंढें।
4. स्कीमा से लॉजिक को अलग करना
एप्लीकेशन लेयर में व्यापार लॉजिक लागू करना जो डेटाबेस में होना चाहिए, असंगति का कारण बनता है। ईआरडी को यह निर्देश देना चाहिए कि लॉजिक कहाँ स्थित है।
- डेटाबेस प्रतिबंध: जहां उचित हो, लॉजिक को ट्रिगर या स्टोर्ड प्रोसीजर में स्थानांतरित करें।
- प्रमाणीकरण: सुनिश्चित करें कि एप्लीकेशन लॉजिक डेटाबेस नियमों को बायपास न करे।
- स्पष्टता: ईआरडी नोट्स में यह दर्ज करें कि लॉजिक कहाँ स्थित है।
🔮 डेटा मॉडल को भविष्य के लिए तैयार करना
स्केलेबल सिस्टम भविष्य के लिए तैयार होने चाहिए। ईआरडी आर्किटेक्चर को वृद्धि और परिवर्तन की अपेक्षा करनी चाहिए।
1. विस्तार्यता
एंटिटीज को विस्तार्य बनाने के लिए डिज़ाइन करें। वे अंतर्निहित गुण जो बदल सकते हैं, उनके लिए लचीले डेटा प्रकार या जीएसओएन कॉलम का उपयोग करें, जबकि मूल संरचना को कठोर रखें।
- गुण सेट:परिवर्तनशील गुणों को एक संरचित मानचित्र में स्टोर करें।
- टैग और लेबल:गतिशील मेटाडेटा के लिए की-वैल्यू जोड़े का उपयोग करें।
- संस्करण फील्ड:परिवर्तनों को ट्रैक करने के लिए एंटिटीज में संस्करण संख्या शामिल करें।
2. ऑडिट ट्रेल
डेटा में किए गए हर परिवर्तन को ट्रैक किया जा सकना चाहिए। ईआरडी में ऑडिट टेबल शामिल होनी चाहिए जो बताएं कि किसने क्या और कब बदला।
- इतिहास टेबल:रिकॉर्ड परिवर्तनों का इतिहास बनाए रखें।
- परिवर्तन लॉग:स्कीमा परिवर्तनों को डेटा परिवर्तनों से अलग लॉग करें।
- एक्सेस लॉग:यह ट्रैक करें कि कौन संवेदनशील डेटा को प्रश्न करता है।
3. सुसंगतता और सुरक्षा
डेटा मॉडल को नियामक आवश्यकताओं का पालन करना चाहिए। ईआरडी में यह परिभाषित करना चाहिए कि संवेदनशील डेटा कहाँ स्टोर किया जाता है और इसे कैसे सुरक्षित किया जाता है।
- एन्क्रिप्शन:एन्क्रिप्शन की आवश्यकता वाले फील्ड को चिह्नित करें।
- रखरखाव नीतियाँ:यह परिभाषित करें कि डेटा को स्कीमा में कितने समय तक रखा जाता है।
- एक्सेस नियंत्रण:वे भूमिकाएँ परिभाषित करें जो विशिष्ट एंटिटीज तक पहुँच के लिए अधिकृत हैं।
🏁 आर्किटेक्चरल अखंडता पर अंतिम विचार
स्कीमा ड्रिफ्ट को रोकना बदलाव को सीमित करने के बारे में नहीं है; यह इसे अनुशासन के साथ प्रबंधित करने के बारे में है। एंटिटी रिलेशनशिप डायग्राम को एक मुख्य आर्किटेक्चरल अभिलेख के रूप में लेने से टीमें ऐसे सिस्टम बना सकती हैं जो दोनों बलवान और अनुकूलनीय हैं। मुख्य बात चिंता के विभाजन, सख्त संस्करण प्रबंधन और स्वचालित शासन में है।
जब ईआरडी का सम्मान किया जाता है, तो डेटा मॉडल एक स्थिर आधार बन जाता है जिस पर स्केलेबल एप्लिकेशन बनाए जा सकते हैं। इससे डेवलपर्स पर मानसिक भार कम होता है, संचालन जोखिम कम होता है, और यह सुनिश्चित करता है कि विकास के साथ सिस्टम बनाए रखने योग्य बना रहता है। डायग्राम की आर्किटेक्चर डेटा की स्थिरता को निर्धारित करती है, और इसके बाद व्यवसाय की स्थिरता।
इन पैटर्न को अपनाने के लिए प्रक्रिया और उपकरण में प्रारंभिक निवेश की आवश्यकता होती है। हालांकि, लंबे समय में लाभ एक ऐसा सिस्टम है जो टूटे हुए डेटा कॉन्ट्रैक्ट के निरंतर निवारण के बोझ के बिना शांतिपूर्ण ढंग से विकसित होता है। डेटा मॉडल की अखंडता को प्राथमिकता दें, और सिस्टम उसके अनुसार आगे बढ़ेगा।