Šī raksta mērķis ir izmantot bibliotēkas piemēru shēmas glabātājs parādīt rīkus, kas var ievērojami vienkāršot datu bāzu izstrādes procesu PHP projektos, izmantojot PostgreSQL DBVS.

Šī raksta informācija, pirmkārt, būs noderīga izstrādātājiem, kuri vēlas maksimāli izmantot PostgreSQL iespējas, bet saskaras ar problēmām, kas saistītas ar datubāzē ievietotās biznesa loģikas uzturēšanu.

Šajā rakstā netiks aprakstītas biznesa loģikas glabāšanas priekšrocības vai trūkumi datu bāzē. Tiek pieņemts, ka izvēli jau ir izdarījis lasītājs.

Tiks izskatīti šādi jautājumi:

1. Kādā formā versiju kontroles sistēmā (turpmāk – VCS) jāuzglabā datu bāzes struktūras izgāztuve?
2. Kā izsekot izmaiņām datu bāzes struktūrā pēc izgāztuves saglabāšanas
3. Kā pārsūtīt datu bāzes struktūras izmaiņas uz citām vidēm bez konfliktiem un milzu migrācijas failiem
4. Kā organizēt vairāku izstrādātāju paralēlā darba procesu pie projekta
5. Kā droši izvietot vairāk datu bāzes struktūras izmaiņu ražošanas vidē
   

   SchemaKeeper paredzēts darbam ar saglabātajām procedūrām, kas rakstītas valodā PL/pgSQL. Pārbaude ar citām valodām nav veikta, tāpēc lietošana var nebūt tik efektīva vai arī nav iespējama.

Kā saglabāt datu bāzes struktūras izgāztuvi VCS

Bibliotēka shēmas glabātājs nodrošina funkciju saveDump, kas saglabā visu objektu struktūru no datu bāzes kā atsevišķus teksta failus. Izvade ir direktorijs, kurā ir datu bāzes struktūra, kas sadalīta grupētos failos, kurus var viegli pievienot VCS.

Apskatīsim objektu konvertēšanu no datu bāzes failos, izmantojot vairākus piemērus:

Objekta tips
Shēma
Nosaukums
Relatīvais ceļš uz failu

tabula
valsts
konti
./public/tables/accounts.txt

Saglabātā procedūra
valsts
auth (hash bigint)
./public/functions/auth(int8).sql

Ievads
rezervēšana
tarifi
./booking/views/tariffs.txt

Failu saturs ir konkrēta datu bāzes objekta struktūras teksta attēlojums. Piemēram, saglabātajām procedūrām faila saturs būs pilna saglabātās procedūras definīcija, sākot ar bloku CREATE OR REPLACE FUNCTION.

Kā redzams no iepriekšējās tabulas, ceļš uz failu glabā informāciju par objekta veidu, shēmu un nosaukumu. Šī pieeja atvieglo navigāciju datubāzes izmaiņu izdrukā un koda pārskatā.

pagarināšana .sql failiem ar saglabāto procedūras avota kodu tas tika atlasīts, lai IDE automātiski nodrošinātu rīkus mijiedarbībai ar datu bāzi, kad fails tiek atvērts.

Kā izsekot izmaiņām datu bāzes struktūrā pēc izgāztuves saglabāšanas

Saglabājot pašreizējās datu bāzes struktūras izgāztuvi VCS, mēs iegūstam iespēju pārbaudīt, vai datu bāzes struktūrā tika veiktas izmaiņas pēc izgāztuves izveidošanas. Bibliotēkā shēmas glabātājs lai noteiktu izmaiņas datu bāzes struktūrā, tiek nodrošināta funkcija verifyDump, kas atgriež informāciju par atšķirībām bez blakusparādībām.

Alternatīvs veids, kā pārbaudīt, ir vēlreiz izsaukt funkciju saveDump, norādot to pašu direktoriju, un pārbaudiet VCS, vai nav notikušas izmaiņas. Tā kā visi objekti no datu bāzes tiek saglabāti atsevišķos failos, VCS parādīs tikai mainītos objektus.
Šīs metodes galvenais trūkums ir nepieciešamība pārrakstīt failus, lai redzētu izmaiņas.

Kā pārsūtīt datu bāzes struktūras izmaiņas uz citām vidēm bez konfliktiem un milzu migrācijas failiem

Pateicoties funkcijai deployDump Saglabāto procedūru avota kodu var rediģēt tieši tāpat kā parasto lietojumprogrammas avota kodu. Varat pievienot/dzēst jaunas rindas saglabātajā procedūru kodā un nekavējoties virzīt izmaiņas versiju kontrolei vai izveidot/dzēst saglabātās procedūras, izveidojot/dzēšot atbilstošos failus izgāztuves direktorijā.

Piemēram, lai shēmā izveidotu jaunu saglabāto procedūru public vienkārši izveidojiet jaunu failu ar paplašinājumu .sql direktorijā public/functions, ievietojiet tajā saglabātās procedūras pirmkodu, ieskaitot bloku CREATE OR REPLACE FUNCTION, pēc tam izsauciet funkciju deployDump. Saglabātās procedūras pārveidošana un dzēšana notiek tādā pašā veidā. Tādējādi kods vienlaikus nonāk gan VCS, gan datu bāzē.

Ja jebkuras saglabātās procedūras avota kodā parādās kļūda vai neatbilstības starp faila un saglabātās procedūras nosaukumiem, deployDump neizdosies, parādot kļūdas tekstu. Lietojot, nav iespējama saglabāto procedūru neatbilstība starp izgāztuvi un pašreizējo datu bāzi deployDump.

Veidojot jaunu saglabāto procedūru, nav nepieciešams manuāli ievadīt pareizo faila nosaukumu. Pietiek, ja failam ir paplašinājums .sql. Pēc zvana deployDump kļūdas tekstā būs pareizais nosaukums, ko var izmantot faila pārdēvēšanai.

deployDump ļauj mainīt funkcijas vai atgriešanas veida parametrus bez papildu darbībām, savukārt ar klasisko pieeju tas būtu jādara
izpildīt vispirms DROP FUNCTION, un tikai tad CREATE OR REPLACE FUNCTION.

Diemžēl ir situācijas, kad deployDump nevar automātiski piemērot izmaiņas. Piemēram, ja tiek noņemta sprūda funkcija, ko izmanto vismaz viens trigeris. Šādas situācijas tiek atrisinātas manuāli, izmantojot migrācijas failus.

Ja esat atbildīgs par saglabāto procedūru izmaiņu migrēšanu shēmas glabātājs, tad ir jāizmanto migrācijas faili, lai pārsūtītu citas struktūras izmaiņas. Piemēram, laba bibliotēka darbam ar migrāciju ir doktrīna/migrācijas.

Migrācijas ir jāpiemēro pirms palaišanas deployDump. Tas ļauj veikt visas izmaiņas struktūrā un atrisināt problemātiskās situācijas, lai saglabāto procedūru izmaiņas pēc tam tiktu pārnestas bez problēmām.

Darbs ar migrāciju tiks sīkāk aprakstīts nākamajās sadaļās.

Kā organizēt vairāku izstrādātāju paralēlā darba procesu pie projekta

Ir nepieciešams izveidot skriptu pilnīgai datu bāzes inicializācijai, ko izstrādātājs palaidīs savā darba mašīnā, saskaņojot lokālās datu bāzes struktūru ar VCS saglabāto izgāztuvi. Vienkāršākais veids ir sadalīt vietējās datu bāzes inicializāciju 3 soļos:

1. Importējiet failu ar pamatstruktūru, kas tiks saukts piem. base.sql
2. Migrāciju piemērošana
3. Zvans deployDump

base.sql ir sākumpunkts, uz kura tiek piemērotas un izpildītas migrācijas deployDumpTas ir, base.sql + миграции + deployDump = актуальная структура БД. Jūs varat izveidot šādu failu, izmantojot utilītu pg_dump. Lietots base.sql tikai inicializējot datubāzi no nulles.

Izsauksim skriptu pilnīgai datu bāzes inicializācijai refresh.sh. Darbplūsma varētu izskatīties šādi:

1. Izstrādātājs palaiž savā vidē refresh.sh un iegūst pašreizējo datu bāzes struktūru
2. Izstrādātājs sāk darbu pie konkrētā uzdevuma, pārveidojot vietējo datu bāzi, lai tā atbilstu jaunās funkcionalitātes vajadzībām (ALTER TABLE ... ADD COLUMN utt)
3. Pēc uzdevuma pabeigšanas izstrādātājs izsauc funkciju saveDumpveikt izmaiņas, kas veiktas datubāzē VCS
4. Izstrādātāja atkārtota palaišana refresh.shtad verifyDumpkurā tagad tiek rādīts migrēšanā iekļaujamo izmaiņu saraksts
5. Izstrādātājs pārsūta visas struktūras izmaiņas uz migrācijas failu, palaiž vēlreiz refresh.sh и verifyDump, un, ja migrācija ir apkopota pareizi, verifyDump neparādīs nekādas atšķirības starp vietējo datu bāzi un saglabāto izgāztuvi

Iepriekš aprakstītais process ir saderīgs ar gitflow principiem. Katrs VCS atzars saturēs savu izgāztuves versiju, un, apvienojot filiāles, izgāztuves tiks apvienotas. Vairumā gadījumu pēc sapludināšanas papildu darbības nav jāveic, taču, ja izmaiņas tika veiktas dažādās filiālēs, piemēram, vienā tabulā, var rasties konflikts.

Apskatīsim konfliktsituāciju, izmantojot piemēru: ir filiāle attīstīt, no kuras atzarojas divi zari: iezīme1 и iezīme2, kuriem nav konfliktu ar attīstīt, bet ir konflikti savā starpā. Uzdevums ir apvienot abas filiāles attīstīt. Šajā gadījumā ieteicams vispirms apvienot vienu no filiālēm attīstītun tad apvienot attīstīt uz atlikušo filiāli, atrisinot konfliktus atlikušajā filiālē un pēc tam apvienojot pēdējo filiāli attīstīt. Konfliktu risināšanas fāzē, iespējams, būs jālabo migrācijas fails pēdējā zarā, lai tas atbilstu galīgajai izgāztuvei, kurā ir ietverti sapludināšanas rezultāti.

Kā droši izvietot vairāk datu bāzes struktūras izmaiņu ražošanas vidē

Pateicoties pašreizējās datu bāzes struktūras izgāztuves klātbūtnei VCS, kļūst iespējams pārbaudīt ražošanas datubāzes precīzu atbilstību nepieciešamajai struktūrai. Tas nodrošina, ka visas izstrādātāju iecerētās izmaiņas tika veiksmīgi pārnestas uz ražošanas bāzi.

Kā DDL PostgreSQL ir darījumu, ieteicams ievērot šādu izvietošanas secību, lai negaidītas kļūdas gadījumā varētu “nesāpīgi” izpildīt ROLLBACK:

1. Sāciet darījumu
2. Darījumā veiciet visas migrācijas
3. Tajā pašā darījumā izpildiet deployDump
4. Nepabeidzot darījumu, izpildiet verifyDump. Ja kļūdu nav, palaidiet COMMIT. Ja ir kļūdas, palaidiet ROLLBACK

Šīs darbības var viegli integrēt esošajās lietojumprogrammu izvietošanas pieejās, tostarp bez dīkstāves.

Secinājums

Pateicoties iepriekš aprakstītajām metodēm, no “PHP + PostgreSQL” projektiem ir iespējams izspiest maksimālu veiktspēju, vienlaikus upurējot salīdzinoši nelielas izstrādes ērtības, salīdzinot ar visas biznesa loģikas ieviešanu galvenajā lietojumprogrammas kodā. Turklāt datu apstrāde iekšā PL/pgSQL bieži izskatās pārskatāmāk un prasa mazāk koda nekā tāda pati funkcionalitāte, kas rakstīta PHP.

Avots: www.habr.com