क्या निरंतर निर्माण और तालिकाओं का नष्ट होना एक वास्तु दोष का संकेत है?

Question

हाल ही में मैंने एक डेवलपर के साथ एक चर्चा की, जिसने उल्लेख किया कि कार्यक्रम के विकास के दौरान, वे नियमित रूप से टेबल और स्तंभों को नियमित रूप से बनाते और हटाते हैं, जबकि नई सुविधाओं पर काम करते हैं और यह कहते हुए चीजों को उचित ठहराते हैं कि यह एक चुस्त विकास प्रक्रिया का उपयोग करते समय सामान्य है।

जैसा कि मेरी अधिकांश पृष्ठभूमि एक झरने के विकास के माहौल में है, मुझे आश्चर्य है कि अगर यह वास्तव में चुस्त विकास के तहत उचित माना जाता है, या यदि यह एक अंतर्निहित समस्या का संकेत हो सकता है, या तो कार्यक्रम वास्तुकला के साथ या फुर्तीली प्रक्रिया के बाद उनके साथ।

Comments

डेटाबेस पर एक टिप्पणी, पिछली बार जब यह जाँच की गई थी कि वहाँ 700 से अधिक टेबल हैं और मैंने दूसरों द्वारा उल्लेख किया है कि "इसे फिर से भरने के लिए पर्याप्त समय नहीं है।"

— rjzii

700 टेबल और रिफ्लेक्टर के लिए पर्याप्त समय नहीं? मैं यहाँ पर सभी तरह से असफलता को सूँघ सकता हूँ।

— एडम क्रॉसलैंड

700 इस्तेमाल की गई टेबल या 700 टेबल जिनमें से कई अनाथ हैं?

— बेन ब्रोका

@AdamCrossland गंभीरता से ... लिंगर्ड स्काईनिर्ड की ऊह कि गंध आती है। लेकिन एक गंभीर नोट पर, अपभ्रंश सारणी कभी-कभी रीड-हैवी या डेटाबेस पर एक अच्छा डिज़ाइन विकल्प होती है, जिसमें भारी रिपोर्टिंग लोड होता है।

— maple_shaft

@maple_shaft ज़रूर, किसी भी तकनीक का दुरुपयोग किया जा सकता है, जैसे कुछ भी आपको पेशेवरों / विपक्ष और परीक्षण, परीक्षण का परीक्षण करना होगा। हालाँकि, आप अपने तालिकाओं को अपवित्र करते हुए पाते हैं कि भौतिक विचार आपको बाहर की पेशकश कर सकते हैं। मुझे लगता है कि आपकी बात सिर्फ डीबीए या कम से कम एक डेवलपर के पास मजबूत डीबी-फ़ू के साथ कर्मचारियों पर पुनर्बीमा को वापस लेने के लिए है जब हर कोई स्पष्ट रूप से खराब डिज़ाइन के साथ आगे चार्ज कर रहा है। मेरा सबसे अच्छा काम कोडिंग या डिजाइनिंग के दौरान नहीं आया है, बल्कि दूसरों को भयानक, भयानक निर्णय लेने से रोकना है।

— माइक सेलिनी

Answer 1

यह मेरे लिए हर दिन और अधिक स्पष्ट होता जा रहा है कि "फुर्तीली" खराब सोच-विचार, अराजक, जल्दबाजी और सीट-की-अपनी पैंट का पर्याय बन रहा है। और उन चीजों में से कोई भी एक चुस्त दृष्टिकोण के साथ संगत नहीं है जैसा कि मैं इसे समझता हूं।

एक प्रभावी और दोहराने योग्य चुस्त प्रक्रिया होना आसान नहीं है, और मुझे विश्वास नहीं है कि यह स्वाभाविक रूप से किए जाने वाले काम की कुल मात्रा को कम कर देता है, भले ही यह बेहतर उत्पादों को जन्म दे सके।

यदि उन्होंने कहा है कि उनके पास डेटाबेस को "रिफैक्टर" करने का समय नहीं है, तो संभवतः उनके पास डेटाबेस के लिए संस्करण और प्रवास स्थापित करने का समय नहीं है। उन्होंने शायद इसके लिए कार्यात्मक परीक्षणों का एक सूट बनाने के लिए समय नहीं लिया है। उन सभी चीजों के बारे में जो मुझे लगता है कि जब मैं एक ठोस चुस्त प्रक्रिया के बारे में सोचता हूं जो सफलता के लिए नेतृत्व करती है।

अंत में, एजाइल सिर्फ एक शब्द है। यदि आप सफल हो रहे हैं या नहीं, तो आप दिन-प्रतिदिन निर्धारित कर रहे हैं।

Comments

प्रभावी फुर्तीली प्रक्रिया का मतलब वास्तव में अधिक अग्रिम कार्य होना चाहिए क्योंकि प्रत्येक स्प्रिंट के बाद केवल कार्यात्मक सॉफ्टवेयर देने पर बार-बार ध्यान केंद्रित करना। अगर सही तरीके से किया जाए तो इससे सफलता की बेहतर संभावना बनती है। झरना वास्तव में बहुत अधिक कुशल है यदि आप मानते हैं कि आवश्यकताओं को स्थिर है और परियोजना संसाधन गलती नहीं करते हैं। यह ज्यादातर स्थितियों में कल्पना है।

— maple_shaft

@maple_shaft, बस इतना। चुस्त होने से बिल्डिंग उत्पादों से कड़ी मेहनत नहीं हटती है।

— एडम क्रॉसलैंड

मुझे लगता है कि अगर यह टीम एक झरने के दृष्टिकोण का उपयोग कर रही थी, तो यह केवल अराजक होगा और किसी भी परिवर्तन का अनुरोध एक आपदा होगा।

— जेएफओ

अच्छी तरह से कहा, जेफ ओ।

— एडम क्रॉसलैंड

Answer 2

हालांकि यह एक डिज़ाइन के रूप में टेबल बनाने और छोड़ने के लिए असामान्य नहीं है, कुछ क्लीनअप क्रम में हो सकता है यह सुनिश्चित करने के लिए कि आपका डेटाबेस वास्तव में उन सभी तालिकाओं का उपयोग कर रहा है।

हां, एजाइल रिफैक्टिंग के बारे में है, लेकिन अगर वे अब कह रहे हैं कि सिस्टम रिफ्लेक्टर के लिए बहुत बड़ा है, तो उन्होंने एजाइल करना बंद कर दिया है और अब सिर्फ काउबॉय प्रोग्रामिंग कर रहे हैं। विकास टीम को यह कहा जाना पसंद नहीं होगा, लेकिन यह वही है जो वे कर रहे हैं। कुछ भी चलता है कि रेंज शूटिंग राइडिंग।

एक डीबीए मदद करेगा, बस यह सुनिश्चित करें कि आपको एक डीबीए मिले जो विकास के साथ-साथ फुर्तीले विकास को भी समझे। आपकी विकास टीम को जेल में नहीं फेंकने की जरूरत है।

Answer 3

सामान्य तौर पर, अक्सर नई तालिकाएँ बनाना और नए कॉलम जोड़ना एक प्रक्रिया में बहुत सामान्य है जहाँ प्रोग्रामिंग और डेटाबेस प्रशासन को सख्ती से अलग नहीं किया जाता है। एक नई सुविधा नया डेटा बना सकती है जो कहीं जाना चाहिए। इससे बचने के लिए बहुत सख्ती से प्रयास करें और आप एक आंतरिक-मंच मॉडल के साथ समाप्त होते हैं ।

अच्छी तरह से लिखा सॉफ्टवेयर उन नए डेटाबेस ऑब्जेक्ट्स को शायद ही नोटिस करता है, इसलिए कुछ तालिका में नए कॉलम के कारण कुछ भी नहीं टूटता है।

दूसरी ओर, नियमित रूप से कॉलम या यहां तक ​​कि टेबल ड्रॉप करना संदेहास्पद है। एक नई सुविधा को कभी भी हटाए जाने वाली तालिका की आवश्यकता नहीं होती है, इसलिए यह पूरी तरह से बिना योजना के काम करने वाले लोगों का संकेत हो सकता है।

Comments

नए टेबल और कॉलम का निर्माण मुझे तब तक परेशान नहीं करता है जब यह उचित है, लेकिन यह बताया गया है कि टेबल (और उस मामले के लिए कॉलम) को हटाने का आमतौर पर मतलब है कि किसी काम को अनुचित तरीके से योजना बनाने के कारण खो गया था या कोई अन्य व्यक्ति यह निर्णय ले रहा था सुविधा की जरूरत नहीं थी। इसी तरह, तालिकाओं की कतरनी संख्या उनमें सामान्यीकरण की कमी के कारण एक चिंता का विषय है।

— rjzii

बिल्कुल सही। बड़ी संख्या में तालिकाओं के बारे में चिंता न करें, उनमें से ज्यादातर वैसे भी अप्रयुक्त हैं और शायद उन्हें जल्द ही हटा दिया जाएगा। SCNR

— user281377

खैर, समस्या यह है कि इन सभी का उपयोग किया जाता है, भले ही यह केवल एक रिकॉर्ड के लिए हो।

— rjzii

Answer 4

यदि आपके डेटाबेस को आसानी से संस्करणबद्ध और माइग्रेट किया जा सकता है और आपको यह साबित करने के लिए परीक्षण मिल गए हैं कि चीजें बदलने से चीजें नहीं टूटती हैं, तो संभवतः आपको एक सुंदर चुस्त प्रक्रिया मिल सकती है।

टिप्पणियों के प्रकाश में - आम तौर पर इन के प्रभाव में काउबॉय का एक झुंड होता है जो अपने आप को चुस्त-दुरुस्त चिल्लाता है। तेज। और वह सब पोस्ट करें जो आप thedailywtf.com पर कर सकते हैं ताकि हम सभी आपके आतंक का आनंद ले सकें।

Comments

दुखद बात यह है कि डेटाबेस आसानी से संस्करणित नहीं होता है, माइग्रेट किया जाता है, और सबसे अच्छे स्थान पर सीमित परीक्षण होता है। डेवलपर्स अक्सर अन्य डेवलपर्स द्वारा किए गए परिवर्तनों को ओवरराइट करते हैं।

— rjzii

निश्चित रूप से चरवाहे प्रोग्रामिंग तो। यदि आपके पास इस "फुर्तीली" प्रयास के पीछे एक प्रबंधन टीम है, तो इस टीम को यह सुनिश्चित करने के लिए सुनिश्चित करें कि वे फुर्तीली को गाली दे रहे हैं और बस चल रहे हैं।

— बिल लिपर

@RobZ Agile खराब यूनिट टेस्ट कवरेज और खराब डेटाबेस डिज़ाइन का बहाना नहीं है। यह एक गर्म गंदगी की तरह लगता है।

— maple_shaft

ओह! संस्करण नहीं !!! कोई आश्चर्य नहीं कि यह एक गड़बड़ है। मैं यह सोचकर कांप गया कि ऐप कोड क्या है।

— ozz

मूल रूप से यह टीम कुछ भी चुस्त नहीं कर रही है, वे सिर्फ एक एडहॉक टीम हैं। यदि कोई प्रबंधन संरचना है, तो आप गुमनाम रूप से या व्यक्तिगत रूप से श्रृंखला को लेकर चिंता बढ़ा सकते हैं। उन्हें बताएं कि आप डेटाबेस में भारी गड़बड़ी देख रहे हैं, परीक्षणों की कमी और कोड का प्रबंधन करने के लिए अनुचित प्रथाओं का उपयोग किया जा रहा है। यह टीम एक विशाल विफल के लिए नेतृत्व कर रही है।

— बिल लीपर

Answer 5

StackExchange पर यहाँ अधिकांश उत्तरों की तरह, उत्तर 'यह निर्भर करता है' होना चाहिए। चुस्त विकास में, कार्यान्वयन के दौरान आवश्यकताओं और विशिष्टताओं की खोज की जाती है।

हालांकि, चुस्त विकास को देखते हुए, जब एक संबंधपरक मॉडल को सामान्य रूप से सामान्यीकृत किया जाता है, तो संबंधों में नई विशेषताओं को जोड़ना शायद ही कभी एक आवश्यकता होनी चाहिए, नई संस्थाओं को आमतौर पर पुराने लोगों को संदर्भित करना चाहिए, एक उचित मॉडल दिया जाना चाहिए ।

अधिकांश डेवलपर्स समय-बाधाओं, आलस्य, अक्षमता या क्वेरी जटिलता के कारण अपने DB को सामान्य नहीं करते हैं। नवीनीकरण के लिए मौजूदा डेटा के हस्तांतरण, DAO के संशोधन आदि की आवश्यकता होती है, जो एक जोखिम-कारक उत्पन्न करता है।

Comments

चंचल प्रक्रिया में किस बिंदु पर भविष्य के सभी परिवर्तनों के लिए उचित मॉडल जादुई रूप से प्रकट होता है?

— जेएफओ

डोमेन का ठीक से अध्ययन करने के बाद। संपत्तियों की एक सीमित संख्या है जो पूरी तरह से एक इकाई को परिभाषित करती है। कुछ (तेजी से जटिल) उदाहरण: एक 2 डी बिंदु पूरी तरह से दो निर्देशांक द्वारा परिभाषित किया गया है, एक पता पूरी तरह से एक देश, एक फ़ील्ड संस्करण और किसी अन्य इकाई द्वारा परिभाषित पते फ़ील्ड के एक सेट का अहसास (एक देश आईडी का उपयोग करके, एक संस्करण) और अड़चन)।

— डिब्बेके

@ डिबिबेके: और फिर आपको यूरोपीय संघ (27 देशों) को एक ही देश के मामलों में X, Y और Z. या अमेरिकी राज्यों को देशों के रूप में मानने जैसे व्यापारिक मुद्दे मिलते हैं। या व्यापार बोध कि कुछ DB प्रविष्टियों में एक पते के लिए 2 पता प्रतिनिधित्व हैं।

— मर्सल्ट्स

Answer 6

आपके प्रश्न का उत्तर देने के लिए, नहीं, यह एक चुस्त प्रक्रिया में सामान्य नहीं है।

फुर्तीले रवैये से यह प्रतीत हो सकता है कि एजाइल के लघु-पुनरावृत्ति डिजाइन / विकास / परीक्षण चक्र से है, और हल्के समाधानों पर एजाइल का जोर है जो ज्ञात आवश्यकताओं को पूरा करते हैं, लेकिन नई आवश्यकताओं को पूरा करने में सक्षम होने के लिए अच्छी तरह से संरचित हैं। न्यूनतम परिवर्तन। इन दोनों बातों को देखते हुए, आप कह सकते हैं कि एक डेवलपर, न जाने क्या-क्या नीचे आ सकता है, लेकिन उसके बदलाव को जानने से डीबी पर कोई प्रभाव नहीं पड़ता है, जिसे पूर्ववत नहीं किया जा सकता है, बस स्कीमा में आवश्यक परिवर्तन करता है "सबसे हल्का" संभव है, और फिर अंतराल पर "प्रकाश" परिवर्तनों के कई सेटों को और अधिक स्थायी और स्थिर चीज़ में बदल दिया जाएगा।

यह कहने के बाद कि, मैंने अभी तक एक ऐसे डेवलपर के साथ काम नहीं किया है, जिसने एजाइल सिद्धांत और कार्यप्रणाली की सदस्यता ली हो, और यह भी सोचा कि स्कीमा में नियमित रूप से टेबल बनाना और हटाना किसी भी कारण से आवश्यक था। चंचल का मतलब थप्पड़-डैश या बोल्ट-ऑन नहीं है। यदि आपको एक ऐसी कहानी दी जाती है जिसमें किसी विशेष रिकॉर्ड से संबंधित डेटा के नए क्षेत्र को जोड़ने की आवश्यकता होती है, तो आप फ़ील्ड को तालिका में जोड़ते हैं। यदि वह परिवर्तन कुछ तोड़ता है, तो आप यह पता लगाते हैं कि क्यों, और अन्य परिवर्तन आवश्यक हो सकते हैं (मैं बहुत कम चीजों के बारे में सोच सकता हूं जो एक डीबी के लिए एक कॉलम जोड़कर टूट जाएगा; यदि यह इस तरह के परिवर्तन से टूटता है; बड़ी समस्याएं हैं)। रीफैक्टरिंग आम तौर पर कोड तक सीमित है; स्कीमा को बदलना आमतौर पर कोड बदलने की तुलना में एक अधिक शामिल प्रक्रिया है, और इसलिए जब स्कीमा में परिवर्तन होना चाहिए, तो वे आमतौर पर अधिक देखभाल के साथ किए जाते हैं, और कम से कम कुछ ध्यान परियोजना की भविष्य की दिशा के ज्ञान पर दिया। डेटाबेस के कुछ या सभी को फिर से संरचना करने से डिजाइन की मूलभूत विफलता का संकेत मिलता है; फुर्तीली होने का मतलब यह नहीं है कि कार्यक्रम और डेटा संरचना के निर्माण के दौरान बुनियादी वास्तुकला और डिजाइन नियमों का "मास्टर प्लान" नहीं है।

अब, फुर्तीले में ऐसे मामले हैं जहां आपको "पता" है कि अब आप बाद में क्या सीखेंगे, इसका खंडन किया जाएगा। कहें कि आपके पास एक आवश्यकता है कि आपके सिस्टम में प्रत्येक व्यक्ति के लिए एक पता होना चाहिए। चूंकि यह एक 1: 1 संबंध है और अधिकांश मामलों में डेटा की आवश्यकता होगी, आप बस व्यक्ति फ़ील्ड में पता फ़ील्ड जोड़ते हैं। एक हफ्ते बाद, आपको एक आवश्यकता मिलती है कि एक व्यक्ति के पास एक से अधिक पते हो सकते हैं। अब यह 1: N संबंध है, और इसे ठीक से मॉडल करने के लिए आपको अपने पिछले परिवर्तनों को पूर्ववत करना होगा, फ़ील्ड्स को एक नई पता तालिका में विभाजित करना होगा। यह नियमित नहीं है, खासकर वरिष्ठ डेवलपर्स के बीच। एक अनुभवी डेवलपर यह देखेगा कि एक व्यक्ति का एक पता है, इनको वैचारिक रूप से अलग मानें, और एक व्यक्ति तालिका और एक पता तालिका बनाएं, जिसमें व्यक्ति को एक पते पर एफके संदर्भ के साथ संबोधित किया जाए। एक स्कीमा जैसे कि यह बदलना आसान है रिश्ते की प्रकृति बदलनी चाहिए; संपूर्ण "वाइड" डेटा टेबल बनाए या डिलीट किए बिना, पर्सन और एड्रेस के बीच का संबंध 1: 1 से 1: N से N: N से बहुत आसानी से संशोधित किया जा सकता है।

Answer 7

एजाइल के तहत काम करते समय डिज़ाइन के मोर्चे पर उतना ध्यान नहीं दिया जाता है, इसलिए मुझे यह बहुत बड़ी समस्या नहीं लगती, निश्चित रूप से यह पहली रिलीज़ के लिए है।

ऐसी प्रणाली पर टिप्पणी करना कठिन है जिसमें 700 टेबल हैं जिन्हें मैंने नहीं देखा है, यह उन सभी की अच्छी तरह से आवश्यकता हो सकती है, लेकिन यह भी मामला हो सकता है कि डेटाबेस को पर्याप्त रूप से प्रबंधित नहीं किया गया है।

फुर्तीलेपन के तहत, एक बड़ी प्रणाली के लिए, स्कीमा के प्रभारी के रूप में अभी भी किसी / टीम का होना काफी आम है।

Answer 8

यदि वे बार-बार इस तरह के बदलाव कर रहे हैं - विशेष रूप से लाइव अनुप्रयोगों में टेबल और कॉलम को छोड़ना - जो अनुभवहीनता के संकेत की तरह लगता है। इसका उस प्रक्रिया से कोई लेना-देना नहीं है जिसका वे पालन करने का दावा कर रहे हैं। 'फुर्तीली' एक बहाना नहीं है कि आप बैठकर उस डेटा के बारे में न सोचें , जिसे आपको स्टोर करने की जरूरत है और कोड आउट करने से पहले यह कैसे संबंधित है। यदि वे पाते हैं कि वे प्रारंभिक संरचना के 10-20% से अधिक बदल रहे हैं, तो मेरे लिए एक संकेतक है कि वे या तो चीजों के बारे में नहीं सोच रहे हैं या उनके पास आवश्यकताओं का विश्लेषण करने और डेटाबेस डिजाइन करने का बहुत अनुभव नहीं है, और इसलिए वे बस भी प्राप्त करते हैं शुरुआत में यह बहुत गलत था।

Answer 9

हालांकि ऐसा लगता है कि आपकी टीम वास्तव में केवल काउबॉय कोडिंग है, फिर भी वास्तव में कोड या डेटाबेस को फिर से भरने के साथ कुछ भी गलत नहीं होना चाहिए। यह खोया हुआ काम नहीं है - यह एक नई सीखी हुई वास्तविकता के अनुकूल है।

मेरा सुझाव है कि बदलावों को आज़माने के लिए टीम को एक सैंडबॉक्स की आवश्यकता है, कुछ परीक्षण करें, उन्हें उपयोगकर्ताओं से हटाएं, और निर्णय लें कि क्या वे समझ में आते हैं। उस समय, उन परिवर्तनों को एकीकृत करना जो समझ में आता है - पर्याप्त प्रतिगमन परीक्षण के साथ - आपके स्कीमा में ठीक होना चाहिए।

Answer 10

एजाइल कोडिंग के बारे में है, डेटाबेस कोड नहीं हैं। एक डेटाबेस को बदलना एक घर को फिर से तैयार करने जैसा माना जाना चाहिए। लोगों को किसी तरह विश्वास हो गया कि चंचल का मतलब है अब बाद में योजना बनाना, जो पूरी तरह से असत्य है। यहां तक ​​कि चुस्त तरीकों के तहत नियोजन के लिए समय दिया जाना चाहिए, विशेष रूप से डेटाबेस डिजाइन के रूप में महत्वपूर्ण चीज के लिए।

Comments

डेटाबेस कोड नहीं हैं, लेकिन स्कीमा है और इसे इस तरह से माना जाना चाहिए। यह संस्करण और स्रोत भी नियंत्रित किया जाना चाहिए। मैं इसे कम करना चाहता हूं लेकिन मैं आपके बाकी जवाबों से बहुत ज्यादा सहमत हूं।

— maple_shaft

एजाइल कोडिंग के बारे में नहीं है। यह सॉफ्टवेयर विकास प्रक्रिया के बारे में है, जिसमें निश्चित रूप से डेटाबेस शामिल हैं यदि वर्किंग सॉफ्टवेयर डेटाबेस पर निर्भर करता है। ऐसा कहने के बाद, मैं आपके दावे से सहमत हूं कि एजाइल का अर्थ 'अब बाद में कार्य करना' नहीं है।

— एरिक किंग

@maple_shaft सिर्फ इसलिए कि एक db स्कीमा को कोड की तरह माना जाता है, यह कोड नहीं बनाता है। पालतू जानवरों को लोगों के रूप में माना जाता है, लेकिन यह उन्हें लोगों को नहीं बनाता है

— रयथल

कुछ कोड है या नहीं, इसकी योजना बनाने की आवश्यकता है। मौजूदा डेटा के लिए एक डेटाबेस को बदलने के साथ-साथ बदलते कोड की तरह व्यवहार किया जाना चाहिए। यह वास्तव में अधिक विचार और योजना लेता है।

— जेएफओ

Answer 11

मेरी आखिरी नौकरी इस तरह एक टीम पर थी। एक चुस्त प्रक्रिया का उपयोग करते समय आवश्यकताओं में परिवर्तन होता है। कभी-कभी परिवर्तनों का मतलब है कि मौजूदा इकाई को एक नई विशेषता की आवश्यकता होती है जिसके परिणामस्वरूप मौजूदा तालिका में एक नया कॉलम होता है या पूरी तरह से नई इकाई की आवश्यकता होती है जिसके परिणामस्वरूप मौजूदा तालिकाओं के संबंधों के साथ एक नई तालिका होती है। इस प्रकार के परिवर्तन क्षेत्र के साथ आते हैं और इसे अनदेखा नहीं किया जा सकता क्योंकि आप स्कीमा को स्पर्श नहीं करना चाहते हैं। एक डेटाबेस संस्करण से अगले और उचित इकाई परीक्षण के लिए माइग्रेट करते समय सफलता आपके डेटा की अखंडता को बनाए रखने के द्वारा निर्धारित की जाती है।

बस अपने स्कीमा में अनावश्यक बदलाव न करने का प्रयास करें। उदाहरण के लिए, यदि किसी विशेषता के लिए एक नई तालिका बनाने की आवश्यकता है, तो सुनिश्चित करें कि आप उस तालिका की परिभाषा से खुश हैं इससे पहले कि आप उसे जांच लें और उसे अपने परीक्षण वातावरण में रोल करें। आपके डेटा के माइग्रेट होने के बाद आपके डेटाबेस स्कीमा में बदलाव को पूर्ववत करना दर्दनाक हो सकता है।