Svrha ovog članka je korištenje primjera knjižnice čuvar sheme pokazati alate koji mogu značajno pojednostaviti proces razvoja baza podataka unutar PHP projekata pomoću PostgreSQL DBMS-a.

Informacije iz ovog članka će prije svega biti korisne programerima koji žele maksimalno iskoristiti PostgreSQL mogućnosti, ali su suočeni s problemima održavanja poslovne logike smještene u bazi podataka.

Ovaj članak neće opisivati ​​prednosti ili nedostatke pohranjivanja poslovne logike u bazi podataka. Pretpostavlja se da je čitatelj već napravio izbor.

Razmatrat će se sljedeća pitanja:

1. U kojem obliku bi se dump strukture baze podataka trebao pohraniti u sustav kontrole verzija (u daljnjem tekstu VCS)
2. Kako pratiti promjene u strukturi baze podataka nakon spremanja dumpa
3. Kako prenijeti promjene u strukturi baze podataka u druga okruženja bez sukoba i ogromnih datoteka za migraciju
4. Kako organizirati proces paralelnog rada na projektu od strane nekoliko programera
5. Kako sigurno primijeniti više promjena u strukturi baze podataka u proizvodnom okruženju
   

   SchemaKeeper dizajniran za rad s pohranjenim procedurama napisanim na jeziku PL/pgSQL. Testiranje s drugim jezicima nije provedeno, tako da upotreba možda neće biti tako učinkovita ili možda neće biti moguća.

Kako pohraniti dump strukture baze podataka u VCS

knjižnica čuvar sheme pruža funkciju saveDump, koji sprema strukturu svih objekata iz baze podataka kao zasebne tekstualne datoteke. Izlaz je direktorij koji sadrži strukturu baze podataka, podijeljenu u grupirane datoteke koje se mogu jednostavno dodati u VCS.

Pogledajmo pretvaranje objekata iz baze podataka u datoteke koristeći nekoliko primjera:

Vrsta objekta
Shema
ime
Relativna staza do datoteke

stol
javni
računi
./public/tables/accounts.txt

Pohranjeni postupak
javni
auth (hash bigint)
./public/functions/auth(int8).sql

ideja
rezerviranje
tarife
./booking/views/tariffs.txt

Sadržaj datoteka je tekstualni prikaz strukture određenog objekta baze podataka. Na primjer, za pohranjene procedure, sadržaj datoteke bit će puna definicija pohranjene procedure, počevši od bloka CREATE OR REPLACE FUNCTION.

Kao što se može vidjeti iz gornje tablice, put do datoteke pohranjuje informacije o vrsti, shemi i nazivu objekta. Ovaj pristup olakšava navigaciju kroz dump i pregled koda promjena u bazi podataka.

nastavak .sql za datoteke s izvornim kodom pohranjene procedure, ovo je odabrano tako da IDE automatski pruža alate za interakciju s bazom podataka kada se datoteka otvori.

Kako pratiti promjene u strukturi baze podataka nakon spremanja dumpa

Spremanjem dumpa trenutne strukture baze podataka u VCS-u, dobivamo priliku provjeriti jesu li napravljene promjene u strukturi baze podataka nakon što je dump napravljen. U knjižnici čuvar sheme za otkrivanje promjena u strukturi baze podataka postoji funkcija verifyDump, koji vraća informacije o razlikama bez nuspojava.

Alternativni način provjere je ponovni poziv funkcije saveDump, navodeći isti direktorij i provjerite promjene u VCS-u. Budući da su svi objekti iz baze podataka spremljeni u zasebne datoteke, VCS će prikazati samo promijenjene objekte.
Glavni nedostatak ove metode je potreba za brisanjem datoteka kako bi se vidjele promjene.

Kako prenijeti promjene u strukturi baze podataka u druga okruženja bez sukoba i ogromnih datoteka za migraciju

Zahvaljujući funkciji deployDump Izvorni kod pohranjenih procedura može se uređivati ​​na potpuno isti način kao izvorni kod obične aplikacije. Možete dodati/izbrisati nove retke u kodu pohranjene procedure i odmah unijeti promjene u kontrolu verzija ili stvoriti/izbrisati pohranjene procedure stvaranjem/brisanjem odgovarajućih datoteka u direktoriju ispisa.

Na primjer, za stvaranje nove pohranjene procedure u shemi public samo stvorite novu datoteku s ekstenzijom .sql u imeniku public/functions, u njega smjestite izvorni kod pohranjene procedure, uključujući blok CREATE OR REPLACE FUNCTION, zatim pozovite funkciju deployDump. Modificiranje i brisanje pohranjene procedure događa se na isti način. Dakle, kod ide u VCS i bazu podataka u isto vrijeme.

Ako se pojavi pogreška u izvornom kodu bilo koje pohranjene procedure ili nepodudarnost između imena datoteke i pohranjene procedure, deployDump neće uspjeti, prikazujući tekst pogreške. Neusklađenost pohranjenih procedura između dumpa i trenutne baze podataka nije moguća pri korištenju deployDump.

Prilikom stvaranja nove pohranjene procedure, nema potrebe za ručnim unosom ispravnog naziva datoteke. Dovoljno je da datoteka ima ekstenziju .sql. Nakon poziva deployDump tekst pogreške sadržavat će ispravan naziv, koji se može koristiti za preimenovanje datoteke.

deployDump omogućuje promjenu parametara funkcije ili vrste povrata bez dodatnih radnji, dok biste s klasičnim pristupom morali
izvrši prvi DROP FUNCTION, i tek tada CREATE OR REPLACE FUNCTION.

Nažalost, postoje situacije u kojima deployDump ne može automatski primijeniti promjene. Na primjer, ako se ukloni funkcija okidača koju koristi barem jedan okidač. Takve se situacije rješavaju ručno pomoću datoteka za migraciju.

Ako ste odgovorni za migraciju promjena u pohranjene procedure čuvar sheme, tada se datoteke za migraciju moraju koristiti za prijenos ostalih promjena u strukturi. Na primjer, dobra biblioteka za rad s migracijama je doktrina/seobe.

Migracije se moraju primijeniti prije pokretanja deployDump. To vam omogućuje da napravite sve promjene u strukturi i riješite problematične situacije tako da se promjene u pohranjenim procedurama kasnije bez problema prenesu.

Rad s migracijama bit će detaljnije opisan u sljedećim odjeljcima.

Kako organizirati proces paralelnog rada na projektu od strane nekoliko programera

Za potpunu inicijalizaciju baze potrebno je izraditi skriptu koju će programer pokrenuti na svom radnom stroju, dovodeći strukturu lokalne baze u sklad s dumpom spremljenim u VCS. Najlakši način je podijeliti inicijalizaciju lokalne baze podataka u 3 koraka:

1. Uvezite datoteku s osnovnom strukturom koja će se zvati npr. base.sql
2. Primjena migracija
3. poziv deployDump

base.sql je početna točka na vrhu koje se primjenjuju i izvršavaju migracije deployDumpTo je, base.sql + миграции + deployDump = актуальная структура БД. Možete stvoriti takvu datoteku pomoću uslužnog programa pg_dump. korišteno base.sql isključivo kod inicijalizacije baze podataka od nule.

Pozovimo skriptu za potpunu inicijalizaciju baze podataka refresh.sh. Tijek rada može izgledati ovako:

1. Programer pokreće u svom okruženju refresh.sh i dobiva trenutnu strukturu baze podataka
2. Razvojni programer počinje raditi na zadatku, mijenjajući lokalnu bazu podataka kako bi zadovoljila potrebe nove funkcionalnosti (ALTER TABLE ... ADD COLUMN itd.)
3. Nakon završetka zadatka, programer poziva funkciju saveDumpza uvrštavanje promjena u bazi podataka u VCS-u
4. Ponovno pokretanje programera refresh.sh, onda verifyDumpkoji sada prikazuje popis promjena koje treba uključiti u migraciju
5. Programer prenosi sve promjene strukture u datoteku za migraciju, pokreće ponovno refresh.sh и verifyDump, i, ako je migracija ispravno sastavljena, verifyDump neće pokazati nikakve razlike između lokalne baze podataka i spremljenog dumpa

Gore opisani proces kompatibilan je s načelima gitflowa. Svaka grana u VCS-u će sadržavati vlastitu verziju dumpa, a prilikom spajanja grana, dumpovi će se spojiti. U većini slučajeva nije potrebno poduzimati dodatne radnje nakon spajanja, ali ako su promjene napravljene u različitim granama, na primjer, u istoj tablici, može doći do sukoba.

Razmotrimo konfliktnu situaciju na primjeru: postoji grana razviti, iz koje se granaju dvije grane: feature1 и feature2, koji nemaju sukoba s razviti, ali imaju međusobne sukobe. Zadatak je spojiti obje grane u razviti. U ovom slučaju, preporuča se prvo spojiti jednu od grana u razvitia zatim spojiti razviti u preostalu granu, rješavanje sukoba u preostaloj grani, a zatim spajanje posljednje grane u razviti. Tijekom faze rješavanja sukoba, možda ćete morati popraviti datoteku migracije u posljednjoj grani tako da odgovara konačnom dumpu, koji uključuje rezultate spajanja.

Kako sigurno primijeniti više promjena u strukturi baze podataka u proizvodnom okruženju

Zahvaljujući prisutnosti dumpa trenutne strukture baze podataka u VCS-u, postaje moguće provjeriti točnu usklađenost proizvodne baze podataka sa traženom strukturom. Time se osigurava da su sve promjene koje su programeri namjeravali uspješno prenijete u proizvodnu bazu.

Kao DDL u PostgreSQL je transakcijski, preporuča se pridržavati se sljedećeg redoslijeda postavljanja, kako biste u slučaju neočekivane pogreške mogli „bezbolno“ izvršiti ROLLBACK:

1. Započni transakciju
2. Izvedite sve migracije u transakciji
3. U istoj transakciji izvršite deployDump
4. Bez dovršetka transakcije, izvršite verifyDump. Ako nema grešaka, pokrenite COMMIT. Ako ima grešaka, pokrenite ROLLBACK

Ovi se koraci mogu jednostavno integrirati u postojeće pristupe implementaciji aplikacije, uključujući nulto vrijeme prekida rada.

Zaključak

Zahvaljujući gore opisanim metodama, moguće je iz “PHP + PostgreSQL” projekata izvući maksimalnu izvedbu, a pritom žrtvovati relativno malo pogodnosti razvoja u usporedbi s implementacijom cjelokupne poslovne logike u kodu glavne aplikacije. Štoviše, obrada podataka u PL/pgSQL često izgleda transparentnije i zahtijeva manje koda od iste funkcije napisane u PHP-u.

Izvor: www.habr.com