यस लेखको उद्देश्य पुस्तकालयको उदाहरण प्रयोग गर्नु हो योजना-किपर PostgreSQL DBMS प्रयोग गरेर PHP परियोजनाहरू भित्र डाटाबेसहरू विकास गर्ने प्रक्रियालाई महत्त्वपूर्ण रूपमा सरल बनाउन सक्ने उपकरणहरू देखाउनुहोस्।

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

यस लेखले डेटाबेसमा व्यापार तर्क भण्डारण गर्ने फाइदा वा बेफाइदाहरू वर्णन गर्दैन। यो मानिन्छ कि पाठक द्वारा पहिले नै छनौट गरिएको छ।

निम्न प्रश्नहरू विचार गरिनेछ:

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

   स्किमकिपर भाषामा लेखिएका भण्डारण प्रक्रियाहरूसँग काम गर्नका लागि डिजाइन गरिएको PL/pgSQL। अन्य भाषाहरूसँग परीक्षण गरिएको छैन, त्यसैले प्रयोग त्यति प्रभावकारी नहुन सक्छ वा सम्भव नहुन सक्छ।

VCS मा डाटाबेस संरचना डम्प कसरी भण्डारण गर्ने

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

धेरै उदाहरणहरू प्रयोग गरेर डाटाबेसबाट वस्तुहरूलाई फाइलहरूमा रूपान्तरण गर्ने बारे हेरौं:

वस्तु प्रकार
योजना
शीर्षक
फाइलमा सापेक्ष बाटो

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

भण्डारण प्रक्रिया
सार्वजनिक
प्रमाण (ह्यास बिजिन्ट)
./public/functions/auth(int8).sql

परिचय
बुकिंग
शुल्कहरू
./booking/views/tariffs.txt

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

माथिको तालिकाबाट देख्न सकिन्छ, फाइलको मार्गले वस्तुको प्रकार, स्कीमा र नामको बारेमा जानकारी भण्डारण गर्छ। यो दृष्टिकोणले डाटाबेसमा परिवर्तनहरूको डम्प र कोड समीक्षा मार्फत नेभिगेट गर्न सजिलो बनाउँछ।

विस्तार .sql भण्डारण प्रक्रिया स्रोत कोड भएका फाइलहरूको लागि, यो चयन गरिएको थियो ताकि IDE ले फाइल खोल्दा डाटाबेससँग अन्तरक्रिया गर्नका लागि स्वचालित रूपमा उपकरणहरू उपलब्ध गराउँछ।

डम्प बचत गरेपछि डाटाबेस संरचनामा परिवर्तनहरू कसरी ट्र्याक गर्ने

VCS मा हालको डाटाबेस ढाँचाको डम्प बचत गरेर, हामीले डम्प सिर्जना गरेपछि डाटाबेस संरचनामा परिवर्तनहरू गरिएको थियो कि छैन भनेर जाँच गर्ने मौका पाउँछौं। पुस्तकालयमा योजना-किपर डाटाबेस संरचनामा परिवर्तनहरू पत्ता लगाउन, एक प्रकार्य प्रदान गरिएको छ 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। यसले तपाइँलाई संरचनामा सबै परिवर्तनहरू गर्न र समस्याग्रस्त अवस्थाहरू समाधान गर्न अनुमति दिन्छ ताकि भण्डारण प्रक्रियाहरूमा परिवर्तनहरू पछि समस्या बिना स्थानान्तरण गरिन्छ।

माइग्रेसनहरूसँग काम गर्ने बारे थप विवरणहरू निम्न खण्डहरूमा वर्णन गरिनेछ।

धेरै विकासकर्ताहरू द्वारा परियोजनामा ​​समानान्तर कार्यको प्रक्रिया कसरी व्यवस्थित गर्ने

डाटाबेसको पूर्ण प्रारम्भिकरणको लागि स्क्रिप्ट सिर्जना गर्न आवश्यक छ, जुन विकासकर्ताले आफ्नो कामको मेसिनमा सुरू गर्नेछ, स्थानीय डाटाबेसको संरचनालाई VCS मा बचत गरिएको डम्प अनुसार ल्याएर। स्थानीय डाटाबेसको प्रारम्भिकरणलाई 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 स्थानीय डाटाबेस र सुरक्षित डम्प बीच कुनै भिन्नता देखाउने छैन

माथि वर्णन गरिएको प्रक्रिया gitflow सिद्धान्तहरूसँग उपयुक्त छ। VCS मा प्रत्येक शाखाले डम्पको आफ्नै संस्करण समावेश गर्दछ, र शाखाहरू मर्ज गर्दा, डम्पहरू मर्ज हुनेछन्। धेरैजसो अवस्थामा, मर्ज पछि कुनै थप कार्यहरू लिनु पर्दैन, तर यदि फरक शाखाहरूमा परिवर्तनहरू गरियो, उदाहरणका लागि, एउटै तालिकामा, द्वन्द्व उत्पन्न हुन सक्छ।

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

कसरी सुरक्षित रूपमा डाटाबेस संरचनामा थप परिवर्तनहरू उत्पादन वातावरणमा तैनात गर्ने

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

पछि DDL PostgreSQL मा छ लेनदेन, यो निम्न तैनाती आदेश पालन गर्न सिफारिस गरिएको छ, ताकि, एक अप्रत्याशित त्रुटि को घटना मा, तपाईं "पीडा बिना" कार्यान्वयन गर्न सक्नुहुन्छ। ROLLBACK:

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

यी चरणहरू सजिलैसँग शून्य-डाउनटाइम सहित एप्लिकेसन डिप्लोइमेन्टमा अवस्थित दृष्टिकोणहरूमा एकीकृत गर्न सकिन्छ।

निष्कर्षमा

माथि वर्णन गरिएका विधिहरूको लागि धन्यवाद, "PHP + PostgreSQL" परियोजनाहरूबाट अधिकतम प्रदर्शन निचोड गर्न सम्भव छ, जबकि मुख्य एप्लिकेसन कोडमा सबै व्यापार तर्कहरू लागू गर्ने तुलनामा अपेक्षाकृत थोरै विकास सुविधाको त्याग गर्दै। यसबाहेक, डाटा प्रोसेसिंग मा PL/pgSQL प्राय: अधिक पारदर्शी देखिन्छ र PHP मा लेखिएको समान कार्यक्षमता भन्दा कम कोड चाहिन्छ।

स्रोत: www.habr.com