Namen tega članka je uporaba primera knjižnice skrbnik sheme pokazati orodja, ki lahko bistveno poenostavijo proces razvoja baz podatkov znotraj PHP projektov z uporabo DBMS PostgreSQL.

Podatki iz tega članka bodo v prvi vrsti koristni razvijalcem, ki želijo kar najbolje izkoristiti zmogljivosti PostgreSQL, a se soočajo s težavami pri vzdrževanju poslovne logike, postavljene v bazi podatkov.

Ta članek ne bo opisoval prednosti ali slabosti shranjevanja poslovne logike v bazi podatkov. Predpostavlja se, da je bralec že izbral.

Obravnavana bodo naslednja vprašanja:

1. V kakšni obliki naj bo izpis strukture baze podatkov shranjen v sistemu za nadzor različic (v nadaljevanju VCS)
2. Kako slediti spremembam v strukturi baze podatkov po shranjevanju izpisa
3. Kako prenesti spremembe v strukturi baze podatkov v druga okolja brez konfliktov in ogromnih selitvenih datotek
4. Kako organizirati proces vzporednega dela na projektu več razvijalcev
5. Kako varno uvesti več sprememb v strukturi baze podatkov v produkcijsko okolje
   

   SchemaKeeper zasnovan za delo s shranjenimi postopki, napisanimi v jeziku PL / pgSQL. Testiranje z drugimi jeziki ni bilo izvedeno, zato uporaba morda ne bo tako učinkovita ali morda nemogoča.

Kako shraniti izpis strukture baze podatkov v VCS

Knjižnica skrbnik sheme zagotavlja funkcijo saveDump, ki shrani strukturo vseh objektov iz baze podatkov kot ločene besedilne datoteke. Izhod je imenik, ki vsebuje strukturo baze podatkov, razdeljeno na združene datoteke, ki jih je mogoče preprosto dodati v VCS.

Oglejmo si pretvorbo objektov iz baze podatkov v datoteke na več primerih:

Vrsta predmeta
Shema
Ime
Relativna pot do datoteke

miza
javnega
računi
./public/tables/accounts.txt

Shranjeni postopek
javnega
auth (hash bigint)
./public/functions/auth(int8).sql

Uvod
Rezervacija
tarife
./booking/views/tariffs.txt

Vsebina datotek je besedilna predstavitev strukture določenega objekta baze podatkov. Na primer, za shranjene procedure bo vsebina datoteke polna definicija shranjene procedure, začenši z blokom CREATE OR REPLACE FUNCTION.

Kot je razvidno iz zgornje tabele, pot do datoteke hrani informacije o vrsti, shemi in imenu predmeta. Ta pristop olajša krmarjenje po izpisu in pregled kode sprememb v bazi podatkov.

razširitev .sql za datoteke z izvorno kodo shranjene procedure je bilo to izbrano tako, da IDE samodejno zagotovi orodja za interakcijo z bazo podatkov, ko se datoteka odpre.

Kako slediti spremembam v strukturi baze podatkov po shranjevanju izpisa

S shranjevanjem izpisa trenutne strukture baze podatkov v VCS dobimo možnost preveriti, ali so bile po izdelavi izpisa narejene spremembe v strukturi baze podatkov. V knjižnici skrbnik sheme za zaznavanje sprememb v strukturi baze podatkov je na voljo funkcija verifyDump, ki vrne informacije o razlikah brez stranskih učinkov.

Alternativni način preverjanja je ponoven klic funkcije saveDump, pri čemer navedete isti imenik, in preverite VCS za spremembe. Ker so vsi objekti iz baze podatkov shranjeni v ločenih datotekah, bo VCS prikazal samo spremenjene objekte.
Glavna pomanjkljivost te metode je potreba po prepisovanju datotek, da bi videli spremembe.

Kako prenesti spremembe v strukturi baze podatkov v druga okolja brez konfliktov in ogromnih selitvenih datotek

Zahvaljujoč funkciji deployDump Izvorno kodo shranjenih procedur je mogoče urejati na povsem enak način kot izvorno kodo običajne aplikacije. Dodate/izbrišete lahko nove vrstice v kodi shranjene procedure in takoj potisnete spremembe v nadzor različic ali ustvarite/izbrišete shranjene procedure tako, da ustvarite/izbrišete ustrezne datoteke v imeniku izpisa.

Na primer, če želite ustvariti novo shranjeno proceduro v shemi public preprosto ustvarite novo datoteko s pripono .sql v imeniku public/functionsvanj postavite izvorno kodo shranjene procedure, vključno z blokom CREATE OR REPLACE FUNCTION, nato pokličite funkcijo deployDump. Spreminjanje in brisanje shranjene procedure poteka na enak način. Tako gre koda hkrati v VCS in bazo podatkov.

Če se v izvorni kodi katere koli shranjene procedure pojavi napaka ali neskladje med imeni datoteke in shranjene procedure, deployDump ne bo uspelo, prikazano bo besedilo napake. Neusklajenost shranjenih procedur med izpisom in trenutno zbirko podatkov pri uporabi ni mogoča deployDump.

Ko ustvarjate novo shranjeno proceduro, ni treba ročno vnesti pravilnega imena datoteke. Dovolj je, da ima datoteka končnico .sql. Po klicu deployDump besedilo napake bo vsebovalo pravilno ime, ki ga lahko uporabite za preimenovanje datoteke.

deployDump vam omogoča spreminjanje parametrov funkcije ali vrnjenega tipa brez dodatnih dejanj, medtem ko bi pri klasičnem pristopu morali
najprej izvršiti DROP FUNCTION, in šele takrat CREATE OR REPLACE FUNCTION.

Na žalost obstajajo situacije, ko deployDump ni mogoče samodejno uporabiti sprememb. Na primer, če je odstranjena funkcija sprožilca, ki jo uporablja vsaj en sprožilec. Takšne situacije se rešujejo ročno z uporabo selitvenih datotek.

Če ste odgovorni za selitev sprememb v shranjene procedure skrbnik sheme, potem je treba selitvene datoteke uporabiti za prenos drugih sprememb v strukturi. Na primer, dobra knjižnica za delo s selitvami je doktrina/migracije.

Migracije je treba uporabiti pred zagonom deployDump. To vam omogoča, da naredite vse spremembe v strukturi in razrešite problematične situacije, tako da se spremembe v shranjenih procedurah kasneje prenesejo brez težav.

Delo s selitvami bo podrobneje opisano v naslednjih razdelkih.

Kako organizirati proces vzporednega dela na projektu več razvijalcev

Potrebno je izdelati skripto za popolno inicializacijo baze podatkov, ki jo bo razvijalec zagnal na svojem delovnem stroju in s tem uskladil strukturo lokalne baze podatkov z dumpom, shranjenim v VCS. Najlažji način je, da inicializacijo lokalne baze podatkov razdelite na 3 korake:

1. Uvozite datoteko z osnovno strukturo, ki se bo imenovala npr. base.sql
2. Uporaba migracij
3. Izziv deployDump

base.sql je izhodiščna točka, na kateri se uporabljajo in izvajajo migracije deployDumpTo pomeni, da base.sql + миграции + deployDump = актуальная структура БД. Takšno datoteko lahko ustvarite s pomočjo pripomočka pg_dump. Rabljeno base.sql izključno pri inicializaciji baze podatkov od začetka.

Pokličimo skript za popolno inicializacijo baze podatkov refresh.sh. Potek dela bi lahko izgledal takole:

1. Razvijalec zažene v svojem okolju refresh.sh in dobi trenutno strukturo baze podatkov
2. Razvijalec začne delati na zastavljeni nalogi in spremeni lokalno bazo podatkov, da ustreza potrebam nove funkcionalnosti (ALTER TABLE ... ADD COLUMN itd.)
3. Po opravljeni nalogi razvijalec pokliče funkcijo saveDumpza objavo sprememb v bazi podatkov v VCS
4. Ponovni zagon razvijalca refresh.sh, potem verifyDumpki zdaj prikazuje seznam sprememb, ki jih je treba vključiti v selitev
5. Razvijalec prenese vse strukturne spremembe v datoteko za selitev in jo znova zažene refresh.sh и verifyDump, in če je selitev pravilno prevedena, verifyDump ne bo pokazal razlik med lokalno bazo podatkov in shranjenim izpisom

Zgoraj opisani postopek je združljiv z načeli gitflow. Vsaka veja v VCS bo vsebovala svojo različico odlagališča in pri združevanju vej se bodo odlagališča združila. V večini primerov po združitvi ni treba izvesti nobenih dodatnih dejanj, če pa so bile spremembe izvedene v različnih vejah, na primer v isti tabeli, lahko pride do spora.

Razmislimo o konfliktni situaciji na primeru: obstaja podružnica Razvoj, iz katerega se odcepita dve veji: funkcija1 и funkcija2, ki nimajo konfliktov z Razvoj, vendar imajo med seboj konflikte. Naloga je združiti obe veji v Razvoj. V tem primeru je priporočljivo najprej združiti eno od vej v Razvojin nato združiti Razvoj v preostalo vejo, reševanje sporov v preostali veji in nato združitev zadnje veje v Razvoj. Med fazo reševanja sporov boste morda morali popraviti selitveno datoteko v zadnji veji, tako da se ujema s končnim izpisom, ki vključuje rezultate spajanj.

Kako varno uvesti več sprememb v strukturi baze podatkov v produkcijsko okolje

Zahvaljujoč prisotnosti odlagališča trenutne strukture baze podatkov v VCS, postane mogoče preveriti produkcijsko bazo podatkov glede natančne skladnosti z zahtevano strukturo. To zagotavlja, da so bile vse spremembe, ki so jih nameravali razvijalci, uspešno prenesene v produkcijsko bazo.

Kot DDL v PostgreSQL je transakcijski, je priporočljivo, da se držite naslednjega vrstnega reda uvajanja, tako da lahko v primeru nepričakovane napake "neboleče" izvedete ROLLBACK:

1. Začni transakcijo
2. Izvedite vse selitve v transakciji
3. V isti transakciji izvedite deployDump
4. Brez dokončanja transakcije izvedite verifyDump. Če ni napak, zaženite COMMIT. Če so napake, zaženite ROLLBACK

Te korake je mogoče preprosto integrirati v obstoječe pristope k uvajanju aplikacij, vključno z ničelnimi izpadi.

Zaključek

Zahvaljujoč zgoraj opisanim metodam je mogoče iz projektov »PHP + PostgreSQL« iztisniti največjo zmogljivost, pri tem pa žrtvovati razmeroma malo udobja pri razvoju v primerjavi z implementacijo celotne poslovne logike v kodo glavne aplikacije. Še več, obdelava podatkov v PL / pgSQL pogosto izgleda bolj pregledno in zahteva manj kode kot ista funkcionalnost, napisana v PHP.

Vir: www.habr.com