सिद्धांत स्कीमा अपडेट या सिद्धांत माइग्रेशन

Question

केवल स्कीमा अपडेट चलाने पर सिद्धांत माइग्रेशन के व्यावहारिक फायदे क्या हैं?

सुरक्षा?

orm:schema-tool:update आदेश (Symfony में doctrine:schema:update)

इस आपरेशन उत्पादन परिवेश में निष्पादित नहीं किया जाना चाहिए चेतावनी देते हैं।

लेकिन यह क्यों है? निश्चित रूप से, यह डेटा हटा सकता है लेकिन माइग्रेशन भी कर सकता है।

लचीलापन?

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

Answer 1

जब आप schema-tool उपयोग कर रहे हैं, डेटाबेस संशोधन का कोई इतिहास रखा जाता है, और एक उत्पादन/स्टेजिंग वातावरण में यह एक बड़ा नकारात्मक पहलू है।

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

ठीक है, वर्तमान डेटा लाने के लिए एक क्वेरी को समझना इतना मुश्किल नहीं है, इसे तीन मानों में अलग करें और उन्हें वापस डालें। वह तब होता है जब माइग्रेशन खेल में आते हैं: आप अपने नए फ़ील्ड बना सकते हैं, फिर ट्रांसफॉर्म करें और अंत में उस डेटा को छोड़ दें जो पहले डेटा धारण कर रहा था।

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

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

इसके अलावा, माइग्रेशन कुछ ऐसा है जो आपके टीम के ज्ञान पर अन्य डेवलपर्स को अपने स्कीमा को अपडेट करने का समय देता है। केवल schema-tool के साथ, आपके टीम के साथी को प्रत्येक बार खींचने पर doctrine:schema:update चलाने होंगे, क्योंकि वे नहीं जानते होंगे कि स्कीमा वास्तव में बदल गया है या नहीं।

माइग्रेशन का उपयोग करते समय, आप हमेशा देखते हैं कि माइग्रेशन फ़ोल्डर में कुछ अपडेट हैं, जिसका अर्थ है कि आपको अपनी स्कीमा अपडेट करने की आवश्यकता है।

Answer 2

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

तो हाँ, मैं व्यक्तिगत रूप से सोचता हूं कि उत्पादन वातावरण में माइग्रेशन का उपयोग करने का मुख्य कारण सुरक्षा और शायद कुछ लचीलापन है। मुझे लगता है कि सुरक्षा विजेता होगी :)

उम्मीद है कि इससे मदद मिलती है।

संपादित करें: यहाँ Symfony डॉक्स के लिए संदर्भ के साथ एक और जवाब है: Is it safe to use doctrine2 migrations in production environment with symfony2 and php