Svrha ovog članka je korištenje primjera biblioteke šema-čuvar pokazuju alate koji mogu značajno pojednostaviti proces razvoja baza podataka u okviru PHP projekata koristeći PostgreSQL DBMS.

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

Ovaj članak neće opisati prednosti ili nedostatke pohranjivanja poslovne logike u bazu podataka. Pretpostavlja se da je čitalac već napravio izbor.

Razmatrat će se sljedeća pitanja:

1. U kojem obliku treba pohraniti dump strukture baze podataka u sistem kontrole verzija (u daljem 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 nekoliko programera
5. Kako bezbedno primeniti više promena u strukturi baze podataka u proizvodnom okruženju
   

   SchemaKeeper dizajniran za rad sa pohranjenim procedurama napisanim na jeziku PL/pgSQL. Testiranje sa drugim jezicima nije obavljeno, tako da upotreba možda neće biti tako efikasna ili možda neće biti moguća.

Kako pohraniti dump strukture baze podataka u VCS

biblioteka šema-čuvar 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 grupisane datoteke koje se lako mogu dodati u VCS.

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

Vrsta objekta
Shema
Naslov
Relativna putanja do datoteke

sto
javnost
računa
./public/tables/accounts.txt

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

Uvod
rezervacija
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 će biti puna definicija pohranjene procedure, počevši od bloka CREATE OR REPLACE FUNCTION.

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

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

Kako pratiti promjene u strukturi baze podataka nakon spremanja dumpa

Čuvanjem dumpa trenutne strukture baze podataka u VCS, dobijamo priliku da proverimo da li su napravljene promene u strukturi baze podataka nakon što je dump kreiran. U biblioteci šema-čuvar za otkrivanje promjena u strukturi baze podataka, obezbjeđena je funkcija verifyDump, koji vraća informacije o razlikama bez nuspojava.

Alternativni način za provjeru je ponovno pozivanje funkcije saveDump, navodeći isti direktorij i provjerite u VCS-u za promjene. Pošto su svi objekti iz baze podataka pohranjeni u odvojenim datotekama, VCS će prikazati samo promijenjene objekte.
Glavni nedostatak ove metode je potreba za prepisivanjem datoteka kako bi se vidjelo 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 i običan izvorni kod aplikacije. Možete dodati/obrisati nove linije u kodu pohranjene procedure i odmah ubaciti promjene u kontrolu verzija, ili kreirati/brisati pohranjene procedure kreiranjem/brisanjem odgovarajućih datoteka u dump direktoriju.

Na primjer, za kreiranje nove pohranjene procedure u šemi public samo kreirajte novi fajl sa ekstenzijom .sql u imeniku public/functions, postavite izvorni kod pohranjene procedure u nju, uključujući blok CREATE OR REPLACE FUNCTION, zatim pozovite funkciju deployDump. Izmjena i brisanje pohranjene procedure događa se na isti način. Dakle, kod ulazi i u VCS i u bazu podataka u isto vrijeme.

Ako se pojavi greška u izvornom kodu bilo koje pohranjene procedure, ili neslaganje između imena datoteke i pohranjene procedure, tada deployDump neće uspjeti, prikazujući tekst greške. Nepodudaranje pohranjenih procedura između dumpa i trenutne baze podataka je nemoguće kada se koristi deployDump.

Prilikom kreiranja nove pohranjene procedure, nema potrebe da ručno unosite ispravno ime datoteke. Dovoljno je da fajl ima ekstenziju .sql. Nakon poziva deployDump tekst greške će sadržavati ispravno ime, koje se može koristiti za preimenovanje datoteke.

deployDump omogućava vam da promijenite parametre funkcije ili tipa povrata bez dodatnih radnji, dok bi kod klasičnog pristupa morali
izvrši prvo DROP FUNCTION, i tek tada CREATE OR REPLACE FUNCTION.

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

Ako ste odgovorni za migraciju promjena u pohranjene procedure šema-čuvar, tada se datoteke migracije moraju koristiti za prijenos drugih promjena u strukturi. Na primjer, dobra biblioteka za rad s migracijama je doktrina/migracije.

Migracije se moraju primijeniti prije pokretanja deployDump. Ovo vam omogućava da izvršite sve promjene u strukturi i riješite problematične situacije tako da se promjene u pohranjenim procedurama naknadno prenose bez problema.

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

Kako organizirati proces paralelnog rada na projektu nekoliko programera

Potrebno je kreirati skriptu za kompletnu inicijalizaciju baze podataka koju će programer pokrenuti na svojoj radnoj mašini, dovodeći strukturu lokalne baze podataka u skladu sa dumpom sačuvanim u VCS-u. Najlakši način je podijeliti inicijalizaciju lokalne baze podataka u 3 koraka:

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

base.sql je početna točka na koju se primjenjuju i izvršavaju migracije deployDump, to jest base.sql + миграции + deployDump = актуальная структура БД. Možete kreirati takvu datoteku pomoću uslužnog programa pg_dump. Koristi se base.sql isključivo pri inicijalizaciji baze podataka od nule.

Pozovimo skriptu za kompletnu inicijalizaciju baze podataka refresh.sh. Tok rada bi mogao izgledati ovako:

1. Programer pokreće u svom okruženju refresh.sh i dobija trenutnu strukturu baze podataka
2. Programer započinje rad na zadatku koji je pri ruci, modificirajući lokalnu bazu podataka kako bi zadovoljio potrebe nove funkcionalnosti (ALTER TABLE ... ADD COLUMN itd)
3. Nakon završetka zadatka, programer poziva funkciju saveDumpza urezivanje promjena napravljenih u bazi podataka u VCS
4. Ponovno pokretanje programera refresh.sh, onda verifyDumpkoji sada prikazuje listu promjena koje treba uključiti u migraciju
5. Programer prenosi cijelu promjenu strukture u datoteku za migraciju, ponovo je pokreće refresh.sh и verifyDump, i, ako je migracija ispravno sastavljena, verifyDump neće pokazati nikakve razlike između lokalne baze podataka i sačuvanog dumpa

Gore opisani proces je kompatibilan sa principima gitflow-a. Svaka grana u VCS-u će sadržavati svoju verziju dumpa, a kada se stapaju grane, dumpovi će biti spojeni. U većini slučajeva nije potrebno poduzeti 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 koristeći primjer: postoji grana razvijati, iz koje se granaju dvije grane: značajka1 и značajka2, sa kojima nema sukoba razvijati, ali imaju međusobno sukobe. Zadatak je spojiti obje grane u razvijati. U tom slučaju preporučuje se prvo spajanje jedne od grana u razvijatia zatim spojiti razvijati na preostalu granu, rješavanje sukoba u preostaloj grani, a zatim spajanje posljednje grane u razvijati. Tokom 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 bezbedno primeniti više promena u strukturi baze podataka u proizvodnom okruženju

Zahvaljujući prisutnosti dumpa trenutne strukture baze podataka u VCS-u, postaje moguće provjeriti proizvodnu bazu podataka za tačnu usklađenost sa potrebnom strukturom. Ovo osigurava da su sve promjene koje su programeri namjeravali uspješno prenijete u proizvodnu bazu.

Pošto DDL u PostgreSQL je transakcijski, preporučljivo je da se pridržavate sljedećeg rasporeda, kako biste, u slučaju neočekivane greške, mogli "bezbolno" izvršiti ROLLBACK:

1. Započnite transakciju
2. Izvršite sve migracije u transakciji
3. U istoj transakciji izvršite deployDump
4. Izvršite transakciju bez dovršetka transakcije verifyDump. Ako nema grešaka, pokrenite COMMIT. Ako postoje greške, pokrenite ROLLBACK

Ovi koraci se mogu lako integrirati u postojeće pristupe implementaciji aplikacija, uključujući nulto vrijeme zastoja.

zaključak

Zahvaljujući gore opisanim metodama, moguće je izvući maksimalne performanse iz “PHP + PostgreSQL” projekata, dok se žrtvuje relativno malo pogodnosti razvoja u poređenju sa implementacijom sve poslovne logike u kodu glavne aplikacije. Štaviše, obrada podataka u PL/pgSQL često izgleda transparentnije i zahtijeva manje koda od iste funkcionalnosti napisane u PHP-u.

izvor: www.habr.com