Selle artikli eesmärk on näidata raamatukogu schema-keeper tööriistu, mis võimaldavad oluliselt lihtsustada andmebaaside arendamise protsessi PHP-projektides, mis kasutavad PostgreSQL andmebaasihaldussüsteemi.

Käesolevast artiklist on kasu eelkõige arendajatele, kes soovivad maksimaalselt ära kasutada PostgreSQLi võimalusi, kuid seisavad silmitsi äriloogika haldamise probleemidega, mis on viidud andmebaasi.

Artikkel ei käsitle äriloogika hoidmise eeliseid või puudusi andmebaasis. Eeldatakse, et lugeja on valiku juba teinud.

Käsitletakse järgmisi küsimusi:

1. Kuidas säilitada andmebaasi struktuuri varukoopia versioonihaldussüsteemis (edaspidi VCS)
2. Kuidas jälgida andmebaasi struktuuri muutusi pärast varukoopia salvestamist
3. Kuidas edastada andmebaasi struktuuri muutusi teistele keskkondadele ilma konfliktideta ja suuremate migratsioonifailideta
4. Kuidas korraldada mitme arendaja paralleelset töötamist projekti kallal
5. Kuidas turvaliselt juurutada suurem hulk andmebaasi struktuuri muutusi tootmisringkonda
   

   SchemaKeeper on loodud salvestatud protseduuride töötlemiseks, mis on kirjutatud keeles PL/pgSQL. Testimine teiste keeltest ei ole toimunud, seetõttu võib kasutamine olla vähem tõhus või isegi võimatu.

Kuidas salvestada andmebaasi struktuuri dump VCS-is

Raamatukogu schema-keeper pakub funktsiooni saveDump, mis salvestab kõikide objektide struktuuri andmebaasist eraldi tekstifailidena. Tulemuseks luuakse kataloog, mis sisaldab andmebaasi struktuuri, jagatuna rühmitatud failideks, mida on lihtne VCS-i lisada.

Vaadata objekti teisendamist andmebaasist failideks mitmete näidete abil:

Objekti tüüp
Skeem
Nimi
Faili suhteline tee

Tabel
public
accounts
./public/tables/accounts.txt

Salvestatud protseduur
public
auth(hash bigint)
./public/functions/auth(int8).sql

Vaade
booking
tariffs
./booking/views/tariffs.txt

Failide sisu on objekti andmebaasi struktuuri tekstiline esitus. Näiteks salvestatud protseduuride puhul on faili sisuks salvestatud protseduuri täiendav määratlemine, mis algab plokist CREATE OR REPLACE FUNCTION.

Nagu näha ülaltoodud tabelist, sisaldab faili tee teavet objekti tüübi, skeemi ja nime kohta. Selline lähenemine lihtsustab dump'i navigeerimist ja andmebaasi muudatuste arvustamist.

Laiendus .sql protseduuride lähtekoodifailide jaoks on valitud, et IDE-d pakuksid automaatselt tööriistu andmebaasi interaktsiooniks faili avamisel.

Kuidas jälgida andmebaasi struktuuri muutusi pärast varukoopia salvestamist

Salvestades praeguse andmebaasi struktuuri VCS-s, saame kontrollida, kas struktuuri on pärast dumpi loomist muudetud. Raamatukogus schema-keeper andmebaasi struktuuri muutuste tuvastamiseks on ette nähtud funktsioon verifyDump, mis tagastab ilma kõrvalmõjudeta teavet erinevuste kohta.

Alternatiivne kontrollimeetod — kutsuda uuesti välja funktsioon saveDump, märkides sama katalooge, ja kontrollida VCS-is muudatuste olemasolu. Kuna kõik andmebaasi objektid on salvestatud eraldi failidesse, näitab VCS ainult muudetud objekte.
Peamine miinus antud meetodi puhul — failide ümberkirjutamise vajadus muudatuste nägemiseks.

Kuidas edastada andmebaasi struktuuri muutusi teistele keskkondadele ilma konfliktideta ja suuremate migratsioonifailideta

Tänu funktsioonile deployDump Salvestatud protseduuride lähtekoodi saab muuta sama lihtsalt nagu tavalise rakenduse lähtekoodi. Uusi koodiridasid saab lisada või eemaldada salvestatud protseduuride koodis ning kohe saab saata muudatused versioonihaldussüsteemi või luua või kustutada salvestatud protseduure, luues või kustutades vastavaid faile koopia kaustas.

Näiteks uue salvestatud protseduuri loomiseks skeemis public on piisav luua uus fail laiendiga .sql kaustas public/functions, asetada sellesse salvestatud protseduuri lähtekood, sealhulgas plokk CREATE OR REPLACE FUNCTION, seejärel kutsuda välja funktsioon deployDump. Sarnasel viisil toimub salvestatud protseduuri muutmine ja kustutamine. Seega satub kood samal ajal nii VCS-i kui ka andmebaasi.

Kui mõne salvestatud protseduuri lähtekoodis ilmneb viga või tekib vastuolu faili nime ja salvestatud protseduuri vahel, siis deployDump ei toimu, kuvades veateate. Salvestatud protseduuride lahknevus koopia ja praeguse andmebaasi vahel on võimatu, kui kasutatakse deployDump.

Uue salvestatud protseduuri loomisel ei ole vaja käsitsi sisestada õiget faili nime. Piisab, kui failil on laiend .sql. Pärast väljakutsumist deployDump veatekst sisaldab õiget nime, mida saab kasutada faili ümbernimetamiseks.

deployDump võimaldab muuta funktsiooni või tagastatava tüübi parameetreid ilma täiendavate toiminguteta, samas kui klassikalise lähenemise korral oleks olnud vajalik
esiteks teostada DROP FUNCTION, ja alles siis CREATE OR REPLACE FUNCTION.

Kahjuks on olukordi, kus deployDump ei ole suuteline automaatselt muudatusi rakendama. Näiteks, kui eemaldatakse käivitusfunktsioon, mida kasutab vähemalt üks käivitus. Sellised olukorrad lahendatakse käsitsi migratsioonifailide abil.

Kui muutuste eest hälbivates protseduurides vastutab schema-keeper, siis ülejäänud struktuuri muudatuste üleviimiseks tuleb kasutada migratsioonifaile. Näiteks on hea raamatukogu migratsioonide jaoks doctrine/migrations.

Migratsioonid peavad olema rakendatud enne deployDump. See võimaldab teha kõik muudatused struktuuris ja lahendada probleemsed olukorrad, et muudatused hälbivates protseduurides saaks hiljem probleemideta üle kanda.

Migratsioonide töö kohta lähemalt tuleb juttu järgmistes osades.

Kuidas korraldada mitme arendaja paralleelset töötamist projekti kallal

On oluline luua täieliku andmebaasi initsialiseerimise skript, mis käivitatakse arendaja oma töökeskkonnas, et viia kohaliku andmebaasi struktuur vastavusse VCS-i salvestatud dumpiga. Lihtsaim on jagada kohaliku andmebaasi initsialiseerimine kolme etappi:

1. Importida fail põhistruktuuriga, mida saab näiteks nimetada base.sql
2. Rakendada migratsioone
3. Kutse deployDump

base.sql — see on lähtepunt, millele tuginedes rakendatakse migratsioone ja tehakse deployDump, st base.sql + migratsioonid + deployDump = ajakohane andmebaasi struktuur. Sellise faili genereerimiseks saab kasutada utiliiti pg_dump. Seda kasutatakse base.sql ainult andmebaasi initsialiseerimiseks nullist.

Nimetame täieliku andmebaasi initsialiseerimise skripti refresh.sh. Töövoog võiks välja näha järgmiselt:

1. Arendaja käivitab oma keskkonnas refresh.sh ja saab ajakohase andmebaasi struktuuri
2. Arendaja hakkab töötama seatud ülesande kallal, muutes kohaliku andmebaasi vastavalt uue funktsiooni vajadustele (ALTER TABLE ... ADD COLUMN jne)
3. Pärast ülesande täitmist kutsub arendaja välja funktsiooni saveDump, et fikseerida VCS-is andmebaasis tehtud muudatused
4. Arendaja käivitab uuesti refresh.sh, seejärel verifyDump, mis nüüd näitab migratsiooni kaasamise muudatuste loendit
5. Arendaja viib kõik struktuuri muutused üle migratsioonifaili, käivitab selle uuesti refresh.sh ja verifyDump, ja kui migratsioon on korrektselt koostatud, verifyDump näitab see erinevuste puudumist kohaliku andmebaasi ja salvestatud dumpi vahel

Ülaltoodud protsess on kooskõlas gitflow põhimõtetega. Iga haru VCS-is sisaldab oma dumpi versiooni ning harude sulandumisel toimub dumpide ühendamine. Enamasti ei ole pärast sulandumist vaja teha täiendavaid toiminguid, kuid kui erinevates harudes on tehtud muudatusi, näiteks samasse tabelisse, võib tekkida konflikt.

Vaatame konfliktset olukorda näitel: on haru develop, millest on välja kasvanud kaks haru: feature1 ja feature2, mis ei sisalda konflikte develop, kuid omavad üksteisega konflikte. Ülesanne on sulandada mõlemad harud develop. Sellisel juhul soovitatakse kõigepealt sulandada üks harudest develop, seejärel siis develop jätta alles haru, lahendades konfliktid seal, pärast mida sulandada viimane haru develop. Konfliktide lahendamise etapis võib olla vajalik migreerimisfaili muutmine viimases haru, et see vastaks lõppdumpile, mis sisaldab liitumiste tulemusi.

Kuidas turvaliselt juurutada suurem hulk andmebaasi struktuuri muutusi tootmisringkonda

Tänu VCS-s olevatele andmebaasi struktuuri dumpidele on võimalik kontrollida tootmisbaasi täpset vastavust nõutud struktuurile. See tagab, et tootmisbaasi on edukalt kantud kõik muudatused, mida arendajad kavandasid.

Kuna DDL PostgreSQL-is on tehinguline, soovitatakse järgida järgmisi juurutamise etappe, et vajadusel 'valutult' teostada. RULLI TAGASI:

1. Alusta tehingut.
2. Tehingus teosta kõik migratsioonid.
3. Samuti teosta selles tehingus deployDump
4. Ilma tehingut lõpetamata teosta verifyDump. Kui vigu ei ole, teosta COMMIT. Kui vigu on, teosta RULLI TAGASI

Need sammud on piisavalt lihtsalt integreeritavad olemasolevatesse rakenduste juurutamise meetoditesse, sealhulgas zero-downtime'i lähenemistesse.

Kokkuvõte

Ülaltoodud meetodite abil on võimalik maksimeerida «PHP + PostgreSQL» projektide jõudlust, ohverdades samas suhteliselt väikese arenduse mugavuse võrreldes kogu äri-logika realiseerimisega rakenduse põhikoodis. Lisaks sellele, andmete töötlemine PL/pgSQL näeb sageli välja läbipaistvam ja nõuab vähem koodi, kui sama funktsionaalsus, kirjutatud PHP-s.

Allikas: habr.com