इस लेख का उद्देश्य पुस्तकालय के उदाहरण का उपयोग करना है स्कीमा-रक्षक ऐसे उपकरण दिखाएं जो PostgreSQL DBMS का उपयोग करके PHP परियोजनाओं के भीतर डेटाबेस विकसित करने की प्रक्रिया को महत्वपूर्ण रूप से सरल बना सकते हैं।

इस लेख की जानकारी, सबसे पहले, उन डेवलपर्स के लिए उपयोगी होगी जो PostgreSQL क्षमताओं का अधिकतम लाभ उठाना चाहते हैं, लेकिन डेटाबेस में रखे गए व्यावसायिक तर्क को बनाए रखने में समस्याओं का सामना कर रहे हैं।

यह आलेख डेटाबेस में व्यावसायिक तर्क संग्रहीत करने के फायदे या नुकसान का वर्णन नहीं करेगा। यह माना जाता है कि पाठक द्वारा चुनाव पहले ही किया जा चुका है।

निम्नलिखित प्रश्नों पर विचार किया जाएगा:

1. संस्करण नियंत्रण प्रणाली में डेटाबेस संरचना डंप को किस रूप में संग्रहीत किया जाना चाहिए (इसके बाद इसे वीसीएस के रूप में संदर्भित किया जाएगा)
2. डंप को सहेजने के बाद डेटाबेस संरचना में परिवर्तनों को कैसे ट्रैक करें
3. डेटाबेस संरचना में परिवर्तनों को बिना किसी विरोध और विशाल माइग्रेशन फ़ाइलों के अन्य परिवेशों में कैसे स्थानांतरित किया जाए
4. किसी प्रोजेक्ट पर कई डेवलपर्स द्वारा समानांतर कार्य की प्रक्रिया को कैसे व्यवस्थित करें
5. उत्पादन परिवेश में डेटाबेस संरचना में अधिक परिवर्तनों को सुरक्षित रूप से कैसे तैनात करें
   

   स्कीमकीपर भाषा में लिखी संग्रहीत प्रक्रियाओं के साथ काम करने के लिए डिज़ाइन किया गया पीएल/पीजीएसक्यूएल. अन्य भाषाओं के साथ परीक्षण नहीं किया गया है, इसलिए उपयोग उतना प्रभावी नहीं हो सकता है या संभव नहीं हो सकता है।

वीसीएस में डेटाबेस स्ट्रक्चर डंप को कैसे स्टोर करें

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

आइए कई उदाहरणों का उपयोग करके डेटाबेस से ऑब्जेक्ट को फ़ाइलों में परिवर्तित करने पर नज़र डालें:

वस्तु प्रकार
ड्राइविंग
नाम
फ़ाइल से संबंधित पथ

तालिका
सार्वजनिक
खातों
./public/tables/accounts.txt

संग्रहीत प्रक्रिया
सार्वजनिक
ऑथ (हैश बिगिंट)
./public/functions/auth(int8).sql

विचार
बुकिंग
टैरिफ
./booking/views/tariffs.txt

फ़ाइलों की सामग्री एक विशिष्ट डेटाबेस ऑब्जेक्ट की संरचना का एक पाठ्य प्रतिनिधित्व है। उदाहरण के लिए, संग्रहीत प्रक्रियाओं के लिए, फ़ाइल की सामग्री ब्लॉक से शुरू होकर संग्रहीत प्रक्रिया की पूर्ण परिभाषा होगी CREATE OR REPLACE FUNCTION.

जैसा कि उपरोक्त तालिका से देखा जा सकता है, फ़ाइल का पथ ऑब्जेक्ट के प्रकार, स्कीमा और नाम के बारे में जानकारी संग्रहीत करता है। यह दृष्टिकोण डेटाबेस में परिवर्तनों की डंप और कोड समीक्षा के माध्यम से नेविगेट करना आसान बनाता है।

विस्तार .sql संग्रहीत प्रक्रिया स्रोत कोड वाली फ़ाइलों के लिए, इसे चुना गया था ताकि फ़ाइल खोले जाने पर आईडीई स्वचालित रूप से डेटाबेस के साथ बातचीत करने के लिए उपकरण प्रदान करे।

डंप को सहेजने के बाद डेटाबेस संरचना में परिवर्तनों को कैसे ट्रैक करें

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

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

डेटाबेस संरचना में परिवर्तनों को बिना किसी विरोध और विशाल माइग्रेशन फ़ाइलों के अन्य परिवेशों में कैसे स्थानांतरित किया जाए

समारोह के लिए धन्यवाद deployDump संग्रहित प्रक्रियाओं के स्रोत कोड को ठीक उसी तरह से संपादित किया जा सकता है जैसे नियमित एप्लिकेशन स्रोत कोड को। आप संग्रहीत कार्यविधि कोड में नई पंक्तियाँ जोड़/हटा सकते हैं और तुरंत संस्करण नियंत्रण में बदलाव ला सकते हैं, या डंप निर्देशिका में संबंधित फ़ाइलों को बनाकर/हटाकर संग्रहीत कार्यविधियाँ बना/हटा सकते हैं।

उदाहरण के लिए, किसी स्कीमा में एक नई संग्रहीत प्रक्रिया बनाना public बस एक्सटेंशन के साथ एक नई फ़ाइल बनाएं .sql निर्देशिका में public/functions, ब्लॉक सहित इसमें संग्रहीत प्रक्रिया का स्रोत कोड रखें CREATE OR REPLACE FUNCTION, फिर फ़ंक्शन को कॉल करें deployDump. किसी संग्रहीत प्रक्रिया को संशोधित करना और हटाना उसी तरह से होता है। इस प्रकार, कोड एक ही समय में वीसीएस और डेटाबेस दोनों में चला जाता है।

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

नई संग्रहीत प्रक्रिया बनाते समय, मैन्युअल रूप से सही फ़ाइल नाम दर्ज करने की कोई आवश्यकता नहीं है। फ़ाइल में एक्सटेंशन होना ही पर्याप्त है .sql. कॉल के बाद deployDump त्रुटि टेक्स्ट में सही नाम होगा, जिसका उपयोग फ़ाइल का नाम बदलने के लिए किया जा सकता है।

deployDump आपको अतिरिक्त क्रियाओं के बिना किसी फ़ंक्शन के पैरामीटर या रिटर्न प्रकार को बदलने की अनुमति देता है, जबकि शास्त्रीय दृष्टिकोण के साथ आपको ऐसा करना होगा
पहले निष्पादित करें DROP FUNCTION, और केवल तभी CREATE OR REPLACE FUNCTION.

दुर्भाग्य से, कुछ स्थितियाँ ऐसी हैं जहाँ deployDump परिवर्तनों को स्वचालित रूप से लागू करने में असमर्थ. उदाहरण के लिए, यदि कम से कम एक ट्रिगर द्वारा उपयोग किया जाने वाला ट्रिगर फ़ंक्शन हटा दिया जाता है। ऐसी स्थितियों को माइग्रेशन फ़ाइलों का उपयोग करके मैन्युअल रूप से हल किया जाता है।

यदि आप संग्रहीत प्रक्रियाओं में परिवर्तन स्थानांतरित करने के लिए ज़िम्मेदार हैं स्कीमा-रक्षक, तो संरचना में अन्य परिवर्तनों को स्थानांतरित करने के लिए माइग्रेशन फ़ाइलों का उपयोग किया जाना चाहिए। उदाहरण के लिए, माइग्रेशन के साथ काम करने के लिए एक अच्छी लाइब्रेरी है सिद्धांत/प्रवास.

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

माइग्रेशन के साथ कार्य करने का वर्णन निम्नलिखित अनुभागों में अधिक विस्तार से किया जाएगा।

किसी प्रोजेक्ट पर कई डेवलपर्स द्वारा समानांतर कार्य की प्रक्रिया को कैसे व्यवस्थित करें

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

1. एक बुनियादी संरचना वाली फ़ाइल आयात करें जिसे उदाहरण के लिए कहा जाएगा। base.sql
2. माइग्रेशन लागू करना
3. कॉल deployDump

base.sql वह आरंभिक बिंदु है जिसके शीर्ष पर माइग्रेशन लागू और निष्पादित किए जाते हैं deployDumpयही कारण है, base.sql + миграции + deployDump = актуальная структура БД. आप उपयोगिता का उपयोग करके ऐसी फ़ाइल बना सकते हैं pg_dump. इस्तेमाल किया गया base.sql विशेष रूप से डेटाबेस को स्क्रैच से प्रारंभ करते समय।

आइए संपूर्ण डेटाबेस आरंभीकरण के लिए स्क्रिप्ट को कॉल करें refresh.sh. वर्कफ़्लो इस तरह दिख सकता है:

1. डेवलपर अपने परिवेश में लॉन्च करता है refresh.sh और वर्तमान डेटाबेस संरचना प्राप्त करता है
2. डेवलपर नई कार्यक्षमता की आवश्यकताओं को पूरा करने के लिए स्थानीय डेटाबेस को संशोधित करते हुए, मौजूदा कार्य पर काम शुरू करता है (ALTER TABLE ... ADD COLUMN आदि)
3. कार्य पूरा करने के बाद, डेवलपर फ़ंक्शन को कॉल करता है saveDumpवीसीएस में डेटाबेस में किए गए परिवर्तनों को प्रतिबद्ध करने के लिए
4. डेवलपर पुनः लॉन्च refresh.sh, फिर verifyDumpजो अब माइग्रेशन में शामिल किए जाने वाले परिवर्तनों की एक सूची दिखाता है
5. डेवलपर सभी संरचना परिवर्तनों को माइग्रेशन फ़ाइल में स्थानांतरित करता है, फिर से चलाता है refresh.sh и verifyDump, और, यदि माइग्रेशन सही ढंग से संकलित किया गया है, verifyDump स्थानीय डेटाबेस और सहेजे गए डंप के बीच कोई अंतर नहीं दिखाएगा

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

आइए एक उदाहरण का उपयोग करके संघर्ष की स्थिति पर विचार करें: एक शाखा है विकसित करना, जिससे दो शाखाएँ निकलती हैं: feature1 и feature2, जिसका कोई विरोध नहीं है विकसित करना, लेकिन एक दूसरे के साथ संघर्ष करते हैं। कार्य दोनों शाखाओं को एक में मिलाना है विकसित करना. इस मामले के लिए, पहले किसी एक शाखा का विलय करने की अनुशंसा की जाती है विकसित करनाऔर फिर विलय विकसित करना शेष शाखा में, शेष शाखा में विवादों को हल करना, और फिर अंतिम शाखा का विलय करना विकसित करना. विरोध समाधान चरण के दौरान, आपको अंतिम शाखा में माइग्रेशन फ़ाइल को ठीक करना पड़ सकता है ताकि यह अंतिम डंप से मेल खाए, जिसमें विलय के परिणाम शामिल हैं।

उत्पादन परिवेश में डेटाबेस संरचना में अधिक परिवर्तनों को सुरक्षित रूप से कैसे तैनात करें

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

जैसा डीडीएल PostgreSQL में है लेन-देन संबंधी, निम्नलिखित परिनियोजन आदेश का पालन करने की अनुशंसा की जाती है, ताकि अप्रत्याशित त्रुटि की स्थिति में, आप "दर्द रहित" निष्पादित कर सकें ROLLBACK:

1. लेन-देन प्रारंभ करें
2. किसी लेन-देन में सभी माइग्रेशन निष्पादित करें
3. उसी लेन-देन में निष्पादित करें deployDump
4. लेन-देन पूरा किए बिना निष्पादित करें verifyDump. यदि कोई त्रुटि न हो तो चलाएँ COMMIT. यदि त्रुटियाँ हैं, तो चलाएँ ROLLBACK

इन चरणों को शून्य-डाउनटाइम सहित एप्लिकेशन परिनियोजन के मौजूदा तरीकों में आसानी से एकीकृत किया जा सकता है।

निष्कर्ष

ऊपर वर्णित विधियों के लिए धन्यवाद, मुख्य एप्लिकेशन कोड में सभी व्यावसायिक तर्क को लागू करने की तुलना में अपेक्षाकृत कम विकास सुविधा का त्याग करते हुए, "PHP + PostgreSQL" परियोजनाओं से अधिकतम प्रदर्शन प्राप्त करना संभव है। इसके अलावा, डेटा प्रोसेसिंग में पीएल/पीजीएसक्यूएल अक्सर अधिक पारदर्शी दिखता है और PHP में लिखी समान कार्यक्षमता की तुलना में कम कोड की आवश्यकता होती है।

स्रोत: www.habr.com