PHP: टीम के विकास में डेटाबेस संरचना बदलना

PHP की दुनिया में, डेटाबेस संरचना प्रवासन उपकरण अच्छी तरह से जाना जाता है - DoPHrine , CakePHP से Phinx , Laravel से , Yii से - यह पहली बात है जो दिमाग में आई थी। निश्चित रूप से एक दर्जन और हैं। और उनमें से अधिकांश माइग्रेशन के साथ काम करते हैं - डेटाबेस स्कीमा में वृद्धिशील परिवर्तन करने के लिए आदेश।

मैं यह नहीं बताऊंगा कि यह क्यों है, हब पर इस विषय पर बहुत सारे पद हैं उदाहरण के लिए:

• डेटाबेस संरचना का संस्करण विस्थापित: बुनियादी दृष्टिकोण - हालांकि पुराना लेख, सिद्धांत उम्र नहीं है
• विकासवादी डेटाबेस डिजाइन - मार्टिन फाउलर के लेख का अनुवाद, अच्छा विवरण [वृद्धिशील दृष्टिकोण]
• 1440 डेटाबेस माइग्रेशन का अनुभव करें - PostgesSQL के साथ काम करने पर एक व्यावहारिक पोस्ट

इसके अलावा, विभिन्न शाखाओं में डेटाबेस की संरचना में निरंतर परिवर्तन के साथ मेरे टीम वर्क का अनुभव ।

कच्चे SQL बनाम PHP एपीआई

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

किसी ने शिकायत की कि वह ALTER कमांडों के सिंटैक्स को सीखना नहीं चाहता था ... खैर, मुझे नहीं पता, मैंने निर्देशिका खोली और पहाड़ के उदाहरण लिखे, खासकर एक बड़ी परियोजना में।

डेटा माइग्रेशन (INSERT, UPDATE) भी हमेशा SQL में लिखे जाते हैं। क्योंकि आप कभी भी ORM और मॉडल के वर्तमान संस्करण पर भरोसा नहीं कर सकते। एक संशोधन में वे हैं, दूसरे में अब नहीं है।

उदाहरण के लिए:

Rollback Country::delete()->where(....)->execute(); 

डेटाबेस की स्थिति को वापस रोल करना चाहते हैं। और यह PHP वर्ग अब रेपो में नहीं है। आपको अंतिम प्रतिबद्ध देखने की जरूरत है जहां वह था और वहां से वापस रोल करें। Brrr ...

इसलिए, SQL सरल और विश्वसनीय है:

 --TRANSACTION --UP ALTER TABLE authors ADD COLUMN code INT; ALTER TABLE posts ADD COLUMN slug TEXT; UPDATE authors SET ... --DOWN ALTER TABLE authors DROP COLUMN code; ALTER TABLE posts DROP COLUMN slug; 

डीडीएल में लेन-देन

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

दृश्य (दृश्य) और कार्य

यहाँ समस्या यह है कि उन्हें वृद्धिशील रूप से अद्यतन नहीं किया जा सकता है, जैसे तालिकाओं में। DROP और CREATE चाहिए। यानी अंतर पर (प्रवास का पाठ) यह बिल्कुल स्पष्ट नहीं है कि अंत में क्या बदल गया। खासकर जब तर्क को घुमा दिया जाता है, तो यह असुविधाजनक होता है। उदाहरण के लिए:

 --UP DROP VIEW ... CREATE VIEW mvstock AS SELECT (now() - '7 days'::interval) AS refreshed_at, o.pid, COALESCE(sum(o.debit), 0)::integer AS debit, COALESCE(sum(o.credit) FILTER (WHERE d.type <> 104), 0)::integer AS credit, COALESCE(sum(o.debit), 0) - COALESCE(sum(o.credit), 0)::integer AS total FROM operations o JOIN docs d ON d.id = o.doc_id AND d.deleted_at IS NULL WHERE d.closed_at < (now() - '7 days'::interval) AND d.type <> 500 GROUP BY o.pid WITH DATA; --DOWN DROP VIEW ... CREATE VIEW mvstock AS SELECT (now() - '10 days'::interval) AS refreshed_at, o.pid, COALESCE(sum(o.debit), 0)::integer AS debit, COALESCE(sum(o.credit) FILTER (WHERE d.type <> 104), 0)::integer AS credit, COALESCE(sum(o.debit), 0) - COALESCE(sum(o.credit), 0)::integer AS total FROM operations o JOIN docs d ON d.id = o.doc_id AND d.deleted_at IS NULL WHERE d.closed_at < (now() - '10 days'::interval) AND d.type <> 500 GROUP BY o.pid WITH DATA; 

यहाँ क्या बदल गया है?

हम इस तथ्य पर रुक गए कि माइग्रेशन के बगल में एक डैडी है जहां वर्तमान दृश्य और प्रक्रिया कोड संग्रहीत है, जिसे रोलबैक माइग्रेशन में अपडेट और कॉपी किया गया है।

और अब अंतर इस तरह हो जाता है:



एविटो में वापस, हमने संग्रहीत प्रक्रिया कोड को संस्करण के लिए एक दिलचस्प समाधान बनाया ।

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



डेटाबेस संरचना में परिवर्तन को ठीक करने के स्वचालन के लिए Habré पर एक दिलचस्प दृष्टिकोण मिला।

शाखाओं के साथ काम करें

मेरा शाश्वत दर्द दो ए- और बी-शाखाओं के बीच स्विच करने का तरीका है, जिनमें से प्रत्येक में डेटाबेस की संरचना पर संपादन होता है।



ए-शाखा में बैक माइग्रेशन रोल करना आवश्यक है (हमें यह भी याद रखना चाहिए कि कौन सा और कितने), फिर बी-ब्रांच पर स्विच करें और नए माइग्रेशन रोल करें। ठीक है, अगर हमारे संपादन संगत हैं और मैं बस दूसरी शाखा में जा सकता हूं और बी से अतिरिक्त माइग्रेशन रोल कर सकता हूं।

और अगर नहीं? और अगर मेरे पास ऐसी एक से अधिक शाखाएँ हैं? और फिर इन सभी समीक्षा राज्य को वापस रोल करें? मैं हमेशा इससे नफरत करता था ...

अब, किसी और की शाखा में जाने पर, मैं स्वचालित रूप से अन्य लोगों के पलायन को हटा सकता हूं और वर्तमान लोगों को रोल कर सकता हूं:



जहां:

डी - ए-माइग्रेशन जो ए-शाखा में लॉन्च किए गए थे, लेकिन वे वर्तमान शाखा में नहीं हैं, और उन्हें हटाने की सिफारिश की गई है
ए - बी-माइग्रेशन जो नई शाखा में दिखाई दिए और रोल करने की आवश्यकता है

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

क्रमांकन और निष्पादन का क्रम

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



मैं ऐसे मामलों पर विचार नहीं करता जब हमें एक ही चीज़ को संपादित करने की आवश्यकता होती है - ये बिंदु हमेशा सुसंगत होते हैं। खैर, या विधानसभा और परीक्षण के चरण में विफल हो जाएगा।

यहाँ एक दिलचस्प उदाहरण है।

हम एक दृश्य या प्रक्रिया में अलग-अलग संपादन करते हैं, अर्थात्। उन संरचनाओं में जिन्हें विलोपन के माध्यम से अद्यतन किया जाता है। यानी उदाहरण के लिए, मैंने col_A कॉलम को दृश्य में जोड़ा, और मेरे सहयोगी col_B ने। तदनुसार, यदि उसका कोड खदान के बाद बाहर निकलता है, तो उसके कॉलम में मेरा कॉलम नहीं होगा:

 CREATE VIEW vusers AS SELECT login, name, -- .... 

शाखा-ए	शाखा-बी
DROP VIEW vusers; CREATE VIEW vusers AS SELECT login, name, col_A, -- ....	DROP VIEW vusers; CREATE VIEW vusers AS SELECT login, name, col_B, -- ....

इस मामले में, एक शाखा को दूसरे पर निर्भर होना चाहिए।

पलायन में एक और दिलचस्प मामला सुधार है।

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

इन मामलों में, हम एक नई संस्करण संख्या जोड़ते हुए माइग्रेशन फ़ाइल का नाम बदल देते हैं, ताकि माइग्रेटर इसे 2 कमांड के रूप में व्याख्या करना शुरू कर दे - रोल बैक 1 और रोल 2,
उदाहरण के लिए:

रोलबैक

हमेशा रोलबैक लिखें, भले ही वह आधार को उसकी मूल स्थिति में न लौटा सके। उदाहरण के लिए, डीआरओपी टेबल, यह किस प्रकार का रोलबैक हो सकता है?

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

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

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

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

 ALTER TABLE abc ALTER COLUMN code SET NULL 

वाह! परीक्षण के बाद, डेटाबेस NULL मानों से भरा है। रोलबैक करें:

 ALTER TABLE abc ALTER COLUMN code SET NOT NULL 

और इसके विपरीत :-(

आपको कमांड जोड़ने की आवश्यकता है:

 DELETE FROM abc WHERE code IS NULL 

कठिनाई यह है कि आपको इसे ध्यान में रखने की आवश्यकता है और इसे स्वचालित नहीं करें यदि हम हर बार खरोंच से डेटाबेस को फिर से बनाने की बात नहीं कर रहे हैं।

डेटा हटाने के बारे में थोड़ा

आमतौर पर हम एक बार में भरे हुए टेबल और कॉलम को हटाने की कोशिश नहीं करते हैं। नाम बदलने या प्रतिलिपि बनाने के लिए बेहतर है, और बाद में इसे हटा दें, जब सब कुछ बैठ जाता है और डेटा प्रासंगिकता खो देता है:

 ALTER TABLE user_logs RENAME TO user_logs_20190223; --  CREATE TABLE user_logs_20190223 AS TABLE user_logs; 

migrator

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

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

संदर्भ
- माइग्रेशन-लिब
- लारवेल / कारीगर के तहत कार्यान्वयन
- सिम्फनी / कंसोल के तहत कार्यान्वयन