या लेखाचा उद्देश ग्रंथालयाचे उदाहरण वापरणे हा आहे स्कीमा-कीपर अशी साधने दाखवा जी PostgreSQL DBMS वापरून PHP प्रकल्पांमध्ये डेटाबेस विकसित करण्याची प्रक्रिया लक्षणीयरीत्या सुलभ करू शकतात.

या लेखातील माहिती, सर्वप्रथम, ज्या विकासकांना PostgreSQL क्षमतांचा अधिकाधिक फायदा घ्यायचा आहे, परंतु डेटाबेसमध्ये ठेवलेले व्यवसाय तर्क राखण्यात समस्या येत आहेत त्यांच्यासाठी उपयुक्त ठरेल.

हा लेख डेटाबेसमध्ये व्यवसाय तर्क संग्रहित करण्याचे फायदे किंवा तोटे वर्णन करणार नाही. असे गृहीत धरले जाते की निवड वाचकाने आधीच केली आहे.

खालील प्रश्नांचा विचार केला जाईल:

1. आवृत्ती नियंत्रण प्रणालीमध्ये डेटाबेस संरचना डंप कोणत्या स्वरूपात संग्रहित केला जावा (यापुढे व्हीसीएस म्हणून संदर्भित)
2. डंप सेव्ह केल्यानंतर डेटाबेस स्ट्रक्चरमधील बदलांचा मागोवा कसा घ्यावा
3. डेटाबेस संरचनेतील बदल इतर वातावरणात संघर्ष आणि विशाल स्थलांतर फायलींशिवाय कसे हस्तांतरित करावे
4. Как наладить процесс параллельной работы над проектом нескольких разработчиков
5. उत्पादन वातावरणात डेटाबेस संरचनेतील अधिक बदल सुरक्षितपणे कसे तैनात करावे
   

   स्कीमकीपर भाषेत लिहिलेल्या संग्रहित प्रक्रियेसह कार्य करण्यासाठी डिझाइन केलेले PL/pgSQL. इतर भाषांसह चाचणी केली गेली नाही, म्हणून वापर तितका प्रभावी असू शकत नाही किंवा शक्य होणार नाही.

VCS मध्ये डेटाबेस स्ट्रक्चर डंप कसा संग्रहित करायचा

लायब्ररी स्कीमा-कीपर एक कार्य प्रदान करते saveDump, जे डेटाबेसमधील सर्व ऑब्जेक्ट्सची रचना स्वतंत्र मजकूर फाइल्स म्हणून जतन करते. आउटपुट ही डेटाबेस रचना असलेली निर्देशिका आहे, जी समूहबद्ध फायलींमध्ये विभागली आहे जी VCS मध्ये सहजपणे जोडली जाऊ शकते.

अनेक उदाहरणे वापरून डेटाबेसमधून ऑब्जेक्ट्सचे फाइल्समध्ये रूपांतर करूया:

ऑब्जेक्ट प्रकार
योजना
शीर्षक
फाइलचा सापेक्ष मार्ग

टेबल
सार्वजनिक
खाती
./public/tables/accounts.txt

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

परिचय
बुकिंग
दर
./booking/views/tariffs.txt

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

वरील सारणीवरून पाहिल्याप्रमाणे, फाईलचा मार्ग ऑब्जेक्टचा प्रकार, स्कीमा आणि नाव याबद्दल माहिती संग्रहित करतो. हा दृष्टिकोन डेटाबेसमधील बदलांच्या डंप आणि कोड पुनरावलोकनाद्वारे नेव्हिगेट करणे सोपे करते.

विस्तार .sql संचयित प्रक्रिया स्त्रोत कोड असलेल्या फायलींसाठी, हे निवडले होते जेणेकरून फाइल उघडल्यावर IDE स्वयंचलितपणे डेटाबेसशी संवाद साधण्यासाठी साधने प्रदान करते.

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

व्हीसीएसमध्ये सध्याच्या डेटाबेस स्ट्रक्चरचा डंप सेव्ह करून, डंप तयार झाल्यानंतर डेटाबेस स्ट्रक्चरमध्ये बदल केले गेले आहेत की नाही हे तपासण्याची संधी आम्हाला मिळते. ग्रंथालयात स्कीमा-कीपर डेटाबेस संरचनेतील बदल शोधण्यासाठी, एक फंक्शन दिले जाते verifyDump, जे साइड इफेक्ट्सशिवाय मतभेदांबद्दल माहिती देते.

तपासण्याचा पर्यायी मार्ग म्हणजे फंक्शनला पुन्हा कॉल करणे saveDump, समान निर्देशिकेचा निर्देश करून, आणि बदलांसाठी VCS मध्ये तपासा. डेटाबेसमधील सर्व ऑब्जेक्ट्स वेगळ्या फाइल्समध्ये सेव्ह केल्यामुळे, VCS फक्त बदललेल्या ऑब्जेक्ट्स दाखवेल.
या पद्धतीचा मुख्य तोटा म्हणजे बदल पाहण्यासाठी फायली ओव्हरराईट करणे आवश्यक आहे.

डेटाबेस संरचनेतील बदल इतर वातावरणात संघर्ष आणि विशाल स्थलांतर फायलींशिवाय कसे हस्तांतरित करावे

कार्याबद्दल धन्यवाद deployDump संग्रहित प्रक्रियेचा स्त्रोत कोड नियमित अनुप्रयोग स्त्रोत कोड प्रमाणेच संपादित केला जाऊ शकतो. तुम्ही संग्रहित प्रक्रिया कोडमध्ये नवीन ओळी जोडू/हटवू शकता आणि आवृत्ती नियंत्रणामध्ये बदल करू शकता किंवा डंप निर्देशिकेतील संबंधित फाइल्स तयार/हटवून संग्रहित प्रक्रिया तयार/हटवू शकता.

उदाहरणार्थ, स्कीमामध्ये नवीन संग्रहित प्रक्रिया तयार करणे public फक्त विस्तारासह एक नवीन फाइल तयार करा .sql निर्देशिकेत public/functions, ब्लॉकसह, संचयित प्रक्रियेचा स्त्रोत कोड त्यात ठेवा CREATE OR REPLACE FUNCTION, नंतर फंक्शनला कॉल करा deployDump. संग्रहित प्रक्रिया सुधारणे आणि हटवणे त्याच प्रकारे होते. अशा प्रकारे, कोड एकाच वेळी VCS आणि डेटाबेस दोन्हीमध्ये जातो.

कोणत्याही संग्रहित प्रक्रियेच्या स्त्रोत कोडमध्ये त्रुटी आढळल्यास किंवा फाइलच्या नावांमध्ये आणि संग्रहित प्रक्रियेमध्ये तफावत आढळल्यास, नंतर 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. कार्य पूर्ण केल्यानंतर, विकसक फंक्शनला कॉल करतो saveDumpVCS मधील डेटाबेसमध्ये केलेले बदल करण्यासाठी
4. विकसक पुन्हा लाँच करा refresh.shमग verifyDumpजे आता स्थलांतरामध्ये समाविष्ट करण्यासाठी बदलांची सूची दाखवते
5. विकसक सर्व संरचना बदल स्थलांतर फाइलमध्ये स्थानांतरित करतो, पुन्हा चालतो refresh.sh и verifyDump, आणि, स्थलांतर योग्यरित्या संकलित केले असल्यास, verifyDump स्थानिक डेटाबेस आणि जतन केलेल्या डंपमध्ये कोणताही फरक दाखवणार नाही

वर वर्णन केलेली प्रक्रिया गिटफ्लो तत्त्वांशी सुसंगत आहे. VCS मधील प्रत्येक शाखेत डंपची स्वतःची आवृत्ती असेल आणि शाखा विलीन करताना, डंप विलीन केले जातील. बर्‍याच प्रकरणांमध्ये, विलीनीकरणानंतर कोणतीही अतिरिक्त कारवाई करण्याची आवश्यकता नाही, परंतु जर बदल वेगवेगळ्या शाखांमध्ये केले गेले असतील, उदाहरणार्थ, समान टेबलवर, संघर्ष उद्भवू शकतो.

उदाहरण वापरून संघर्षाच्या परिस्थितीचा विचार करूया: एक शाखा आहे विकसित करा, ज्यापासून दोन शाखा आहेत: वैशिष्ट्य 1 и वैशिष्ट्य 2, ज्याचा कोणताही विरोध नाही विकसित करा, परंतु एकमेकांशी मतभेद आहेत. कार्य दोन्ही शाखांमध्ये विलीन करणे आहे विकसित करा. या प्रकरणात, प्रथम शाखांपैकी एक विलीन करण्याची शिफारस केली जाते विकसित कराआणि नंतर विलीन करा विकसित करा उर्वरित शाखेत, उर्वरित शाखेतील संघर्ष सोडवणे आणि नंतर शेवटची शाखा विलीन करणे विकसित करा. विवाद निराकरण टप्प्यात, तुम्हाला शेवटच्या शाखेत स्थलांतरण फाइल निश्चित करावी लागेल जेणेकरून ती अंतिम डंपशी जुळेल, ज्यामध्ये विलीनीकरणाचे परिणाम समाविष्ट आहेत.

उत्पादन वातावरणात डेटाबेस संरचनेतील अधिक बदल सुरक्षितपणे कसे तैनात करावे

VCS मधील वर्तमान डेटाबेस संरचनेच्या डंपच्या उपस्थितीबद्दल धन्यवाद, आवश्यक संरचनेचे अचूक पालन करण्यासाठी उत्पादन डेटाबेस तपासणे शक्य होते. हे सुनिश्चित करते की डेव्हलपर्सना अभिप्रेत असलेले सर्व बदल उत्पादन बेसवर यशस्वीरित्या हस्तांतरित केले गेले आहेत.

असल्याने डीडीएल PostgreSQL मध्ये आहे व्यवहार, खालील तैनाती ऑर्डरचे पालन करण्याची शिफारस केली जाते, जेणेकरून, अनपेक्षित त्रुटी झाल्यास, आपण "वेदनारहित" कार्यान्वित करू शकता ROLLBACK:

1. व्यवहार सुरू करा
2. व्यवहारात सर्व स्थलांतर करा
3. त्याच व्यवहारात, कार्यान्वित करा deployDump
4. व्यवहार पूर्ण न करता, कार्यान्वित करा verifyDump. काही त्रुटी नसल्यास, चालवा COMMIT. त्रुटी असल्यास, चालवा ROLLBACK

शून्य-डाउनटाइमसह, ऍप्लिकेशन डिप्लॉयमेंटच्या विद्यमान पध्दतींमध्ये हे चरण सहजपणे एकत्रित केले जाऊ शकतात.

निष्कर्ष

वर वर्णन केलेल्या पद्धतींबद्दल धन्यवाद, "PHP + PostgreSQL" प्रकल्पांमधून जास्तीत जास्त कार्यप्रदर्शन पिळणे शक्य आहे, मुख्य ऍप्लिकेशन कोडमधील सर्व व्यावसायिक तर्क लागू करण्याच्या तुलनेत तुलनेने कमी विकास सुविधांचा त्याग करणे. शिवाय, डेटा प्रोसेसिंग मध्ये PL/pgSQL अनेकदा अधिक पारदर्शक दिसते आणि PHP मध्ये लिहिलेल्या समान कार्यक्षमतेपेक्षा कमी कोड आवश्यक असतो.

स्त्रोत: www.habr.com