Cilj ovog članka je, na primjeru biblioteke schema-keeper prikazati alate koji značajno olakšavaju proces razvoja baza podataka unutar PHP projekata koji koriste SDB PostgreSQL.

Informacije iz ovog članka, prije svega, bit će korisne programerima koji žele maksimalno iskoristiti mogućnosti PostgreSQL-a, ali se suočavaju s problemima održavanja poslovne logike smještene u Bazi podataka.

Članak neće opisivati prednosti ili nedostatke pohrane poslovne logike u bazi podataka. Pretpostavlja se da je čitatelj već donio odluku.

Razmotrit će se sljedeća pitanja:

1. Na koji način pohraniti dump strukture baze podataka u sustav kontrole verzija (dalje u tekstu - VCS)
2. Kako pratiti promjene u strukturi baze podataka nakon što se pohrani dump
3. Kako prenijeti promjene u strukturi baze podataka na druga okruženja bez sukoba i gigantskih datoteka migracija
4. Kako uspostaviti proces paralelnog rada na projektu s više programera
5. Kako sigurno implementirati veći broj promjena u strukturi baze podataka na produkcijsko okruženje
   

   SchemaKeeper prilagođen je za rad s pohranjenim procedurama pisanima na jeziku PL/pgSQL. Testiranje s drugim jezicima nije provedeno, stoga korištenje može biti manje učinkovito ili nemoguće.

Na koji način pohraniti dump strukture baze podataka u VCS

Biblioteka schema-keeper nudi funkciju saveDump, koja pohranjuje strukturu svih objekata iz baze podataka u obliku odvojenih tekstualnih datoteka. Na izlazu se stvara direktorij koji sadrži strukturu baze podataka podijeljenu na grupirane datoteke koje se lako mogu dodati u VCS.

Pogledajmo transformaciju objekata iz baze podataka u datoteke na nekoliko primjera:

Tip objekta
Shema
Naziv
Relativna putanja do datoteke

Tablica
public
accounts
./public/tables/accounts.txt

Pohranjena procedura
public
auth(hash bigint)
./public/functions/auth(int8).sql

Prikaz
booking
tariffs
./booking/views/tariffs.txt

Sadržaj datoteka čini tekstualno prikazivanje strukture konkretne Baze podataka. Na primjer, za pohranjene procedure sadržaj datoteke će biti potpuna definicija pohranjene procedure, koja započinje s blokom CREATE OR REPLACE FUNCTION.

Kao što se može vidjeti iz gornje tablice, putanja do datoteke sadrži informacije o tipu, shemi i nazivu objekta. Ovaj pristup olakšava navigaciju kroz dump i pregled promjena u Bazi podataka.

Proširenje .sql za datoteke s izvornih kodom pohranjenih procedura odabrano je kako bi IDE automatski pružio alate za interakciju s BDP-om prilikom otvaranja datoteke.

Kako pratiti promjene u strukturi baze podataka nakon što se pohrani dump

Spremanjem ispisa trenutne strukture BDP-a u VCS, dobivamo mogućnost provjere jesu li izmjene unesene u strukturu baze nakon kreiranja ispisa. U biblioteci schema-keeper za otkrivanje promjena u strukturi BDP-a predviđena je funkcija verifyDump, koja bez sporednih učinaka vraća informacije o razlikama.

Alternativni način provjere — ponovo pozvati funkciju saveDump, navodeći isti direktorij, i provjeriti u VCS-u postoji li promjena. Budući da su svi objekti iz BDP-a pohranjeni u zasebnim datotekama, VCS će pokazati samo izmijenjene objekte.
Glavna mana ovog načina — potreba za prepisivanjem datoteka kako bismo vidjeli promjene.

Kako prenijeti promjene u strukturi baze podataka na druga okruženja bez sukoba i gigantskih datoteka migracija

Zahvaljujući funkciji deployDump izvorni kod pohranjenih procedura može se uređivati na isti način kao i običan izvorni kod aplikacije. Možete dodavati/uklanjati nove retke u kodu pohranjenih procedura i odmah slati promjene u sustav kontrole verzija, ili stvarati/uklanjati pohranjene procedure stvaranjem/uklanjanjem odgovarajućih datoteka u direktoriju s ispisom.

Na primjer, za stvaranje nove pohranjene procedure u shemi public dovoljno je stvoriti novu datoteku s proširenjem .sql u direktoriju public/functions, staviti u nju izvorni kod pohranjene procedure, uključujući blok CREATE OR REPLACE FUNCTION, a zatim pozvati funkciju deployDump. Na sličan način događa se i izmjena i brisanje pohranjene procedure. Tako kod istovremeno ulazi i u VCS i u bazu podataka.

Ako u izvorom kodu neke pohranjene procedure dođe do greške ili nesukladnosti između imena datoteke i pohranjene procedure, tada deployDump neće se izvršiti, prikazujući tekst greške. Nesklad pohranjenih procedura između ispisa i trenutnog BDP-a nemoguće je pri korištenju deployDump.

Pri stvaranju nove pohranjene procedure nije potrebno ručno unositi ispravno ime datoteke. Dovoljno je da datoteka ima proširenje .sql. Nakon pozivanja deployDump tekst greške će sadržavati ispravno ime koje se može koristiti za preimenovanje datoteke.

deployDump omogućava promjenu parametara funkcije ili vraćenog tipa bez dodatnih radnji, dok bi se pri klasičnom pristupu prvo moralo
izvršiti DROP FUNCTION, a tek onda. CREATE OR REPLACE FUNCTION.

Nažalost, postoje neke situacije kada deployDump nema mogućnosti automatskog primjenjivanja promjena. Na primjer, ako se ukloni okidačka funkcija koja se koristi barem od jedne okidačke točke. Takve se situacije rješavaju ručno uz pomoć datoteka za migraciju.

Ako za prijenos promjena u pohranjenim procedurama odgovara sam schema-keeper, tada je potrebno koristiti datoteke migracija za prijenos ostalih promjena u strukturi. Na primjer, dobra biblioteka za rad s migracijama je doctrine/migrations.

Migracije trebaju biti primijenjene prije pokretanja deployDump. To omogućuje uvođenje svih promjena u strukturu i rješavanje problemi, tako da se promjene u pohranjenim procedurama kasnije prenose bez problema.

Detaljnije informacije o radu s migracijama bit će opisane u sljedećim odjeljcima.

Kako uspostaviti proces paralelnog rada na projektu s više programera

Potrebno je stvoriti skriptu za potpunu inicijalizaciju DB-a, koja će se pokretati od strane programera na njegovom radnom računalu, dovodeći strukturu lokalne DB-a u skladu s spremljenim dumpom u VCS-u. Najlakše je podijeliti inicijalizaciju lokalne DB-a u 3 koraka:

1. Uvoz datoteke s osnovnom strukturom, koja će se zvati, na primjer, base.sql
2. Primjena migracija
3. Poziv deployDump

base.sql — to je polazna točka, preko koje se primjenjuju migracije i izvršava se deployDump, odnosno base.sql + migracije + deployDump = aktualna struktura DB. Takvu datoteku moguće je formirati pomoću alata pg_dump. Koristi se base.sql isključivo prilikom inicijalizacije baze podataka od nule.

Nazovimo skriptu za potpunu inicijalizaciju DB-a refresh.sh. Radni proces može izgledati ovako:

1. Programer pokreće u svom okruženju refresh.sh i dobiva aktualnu strukturu DB
2. Programer započinje rad na dodijeljenom zadatku, modificirajući lokalnu DB prema potrebama nove funkcionalnosti (ALTER TABLE ... ADD COLUMN itd)
3. Nakon završetka zadatka, programer poziva funkciju saveDump, kako bi zabilježio u VCS-u promjene napravljene u DB
4. Programer ponovno pokreće refresh.sh, zatim verifyDump, koji sada prikazuje popis promjena za uključivanje u migraciju
5. Programer prenosi sve promjene strukture u datoteku migracije, ponovno pokreće refresh.sh i verifyDump, i ako je migracija sastavljena ispravno, verifyDump prikazat će odsutnost razlika između lokalne DB i spremljenog dumpa

Opisani proces je usklađen s principima gitflow. Svaka grana u VCS-u sadržavat će svoju verziju dumpa, a prilikom spajanja grana doći će do spajanja dumpa. U većini slučajeva nakon spajanja nije potrebno poduzimati nikakve dodatne akcije, ali ako su napravljene promjene u različitim granama, primjerice u istoj tablici, može doći do sukoba.

Razmotrit ćemo sukobnu situaciju na primjeru: postoji grana develop, od koje su odvojene dvije grane: feature1 i feature2, koje nemaju sukoba s develop, ali imaju sukobe između sebe. Cilj je obaviti spajanje obje grane u develop. U takvoj situaciji preporučuje se prvo obaviti spajanje jedne od grana u develop, a zatim spajanje develop u preostalu granu, rješavajući pritom sukobe u preostaloj grani, nakon čega slijedi spajanje posljednje grane u develop. Tijekom faze razrješavanja sukoba možda će biti potrebno ispraviti datoteku migracije u posljednjoj grani kako bi odgovarala konačnom dumpu, koji uključuje rezultate spajanja.

Kako sigurno implementirati veći broj promjena u strukturi baze podataka na produkcijsko okruženje

Zahvaljujući prisutnosti u VCS-u dumpa aktualne strukture BDP-a, postoji mogućnost provjere produkcijske baze na točno usklađenost sa zahtijevanom strukturom. To jamči da su se u produkcijsku bazu uspješno prenijele sve promjene koje su dizajnirali programeri.

Budući da DDL u PostgreSQL-u je transakcijski, preporučuje se pridržavati se sljedećeg redoslijeda implementacije kako biste, u slučaju nepredviđene pogreške, "bezbolno" izvršili ROLLBACK:

1. Započnite transakciju
2. U transakciji izvršite sve migracije
3. U istoj transakciji izvršite deployDump
4. Ne završavajući transakciju, izvršite verifyDump. Ako nema grešaka, izvršite COMMIT. Ako postoje greške, izvršite ROLLBACK

Ovi koraci se relativno lako uklapaju u postojeće pristupe implementaciji aplikacija, uključujući zero-downtime.

Zaključak

Zahvaljujući gore opisanim metodama, može se izvući maksimum performansi iz "PHP + PostgreSQL" projekata, žrtvujući pri tom relativno malu količinu udobnosti razvoja u usporedbi s realizacijom cijele poslovne logike u glavnom kodu aplikacije. Štoviše, obrada podataka u PL/pgSQL često izgleda transparentnije i zahtijeva manje koda nego ista funkcionalnost napisana u PHP-u.

Izvor: habr.com