Artikulu honen helburua liburutegi baten adibidea erabiltzea da eskema-jasotzailea PHP proiektuen barruan datu-baseak garatzeko prozesua nabarmen erraztu dezaketen tresnak erakutsi PostgreSQL DBMS erabiliz.

Artikulu honetako informazioa, lehenik eta behin, PostgreSQL gaitasunei ahalik eta etekinik handiena atera nahi dieten garatzaileentzat baliagarria izango da, baina datu-basean kokatutako negozio-logika mantentzeko arazoak dituztenei.

Artikulu honek ez ditu deskribatuko negozio-logika datu-base batean gordetzearen abantailak edo desabantailak. Hautua irakurleak dagoeneko egin duela suposatzen da.

Honako galdera hauek hartuko dira kontuan:

1. Zein formatan gorde behar da datu-basearen egituraren iraulketa bertsio-kontroleko sistema batean (aurrerantzean VCS deitzen dena)
2. Nola egin datu-basearen egiturako aldaketen jarraipena iraulketa bat gorde ondoren
3. Nola transferitu datu-basearen egituraren aldaketak beste ingurune batzuetara gatazkarik eta migrazio fitxategi erraldoirik gabe
4. Nola antolatu hainbat garatzailek proiektu batean lan paraleloaren prozesua
5. Nola zabaldu datu-basearen egituran aldaketa gehiago produkzio-ingurunean modu seguruan
   

   SchemaKeeper hizkuntzan idatzitako gordetako prozedurekin lan egiteko diseinatua PL/pgSQL. Ez da beste hizkuntza batzuekin probak egin, beraz, baliteke erabilera eraginkorra ez izatea edo posible ez izatea.

Nola gorde datu-basearen egituraren iraulketa VCS-n

Liburutegia eskema-jasotzailea funtzio bat eskaintzen du saveDump, datu-baseko objektu guztien egitura testu fitxategi bereizi gisa gordetzen duena. Irteera datu-basearen egitura duen direktorio bat da, VCSra erraz gehi daitezkeen fitxategi multzotan banatuta.

Ikus dezagun datu-baseko objektuak fitxategi bihurtzea hainbat adibide erabiliz:

Objektu mota
Eskema
Izena
Fitxategirako bide erlatiboa

taula
publikoa
kontuak
./public/tables/accounts.txt

Gordetutako prozedura
publikoa
auth (hash bigint)
./public/functions/auth(int8).sql

ideia
erreserba
tarifak
./booking/views/tariffs.txt

Fitxategien edukiak datu base-objektu jakin baten egituraren testu-adierazpena dira. Adibidez, gordetako prozeduretarako, fitxategiaren edukia gordetako prozeduraren definizio osoa izango da, bloketik hasita. CREATE OR REPLACE FUNCTION.

Goiko taulan ikus daitekeenez, fitxategiaren bideak objektuaren mota, eskema eta izenari buruzko informazioa gordetzen du. Ikuspegi honi esker, datu-baseko aldaketen iraulketa eta kodea berrikustea errazten da.

luzapena .sql gordetako prozeduraren iturburu-kodea duten fitxategietarako, hau hautatu zen, IDEak fitxategia irekitzean datu-basearekin elkarreragiteko tresnak automatikoki eskain ditzan.

Nola egin datu-basearen egiturako aldaketen jarraipena iraulketa bat gorde ondoren

Uneko datu-basearen egituraren iraulketa bat gordez VCSn, iraulketa sortu ondoren datu-basearen egituran aldaketak egin ote diren egiaztatzeko aukera dugu. Liburutegian eskema-jasotzailea datu-basearen egituran aldaketak hautemateko, funtzio bat eskaintzen da verifyDump, desberdintasunei buruzko informazioa bigarren mailako efekturik gabe itzultzen duena.

Egiaztatzeko beste modu bat funtzioari berriro deitzea da saveDump, direktorio bera zehaztuz, eta egiaztatu VCS-n aldaketak ikusteko. Datu-baseko objektu guztiak fitxategi bereizietan gordetzen direnez, VCS-k aldatutako objektuak soilik erakutsiko ditu.
Metodo honen desabantaila nagusia fitxategiak gainidatzi beharra da aldaketak ikusteko.

Nola transferitu datu-basearen egituraren aldaketak beste ingurune batzuetara gatazkarik eta migrazio fitxategi erraldoirik gabe

Funtzioari esker deployDump Biltegiratutako prozeduren iturburu kodea aplikazio arruntaren iturburu kodearen modu berean edita daiteke. Biltegiratutako prozedura-kodean lerro berriak gehi ditzakezu eta berehala bertsio-kontrolerako aldaketak bultza ditzakezu, edo gordetako prozedurak sortu/ezabatu, dagozkion fitxategiak sortuz/ezabatuz iraulketa-direktorioan.

Adibidez, eskema batean gordetako prozedura berri bat sortzeko public besterik gabe sortu fitxategi berri bat luzapenarekin .sql direktorioan public/functions, jarri bertan gordetako prozeduraren iturburu kodea, blokea barne CREATE OR REPLACE FUNCTION, gero deitu funtzioari deployDump. Biltegiratutako prozedura bat aldatzea eta ezabatzea modu berean gertatzen da. Horrela, kodea VCSra eta datu-basean sartzen da aldi berean.

Biltegiratutako edozein prozeduraren iturburu-kodean erroreren bat agertzen bada, edo fitxategiaren eta gordetako prozeduraren izenen arteko desadostasun bat, orduan deployDump huts egingo du, errore-testua erakutsiz. Biltegiratutako prozeduren desegokitzea zabortegiaren eta uneko datu-basearen artean ezinezkoa da erabiltzen denean deployDump.

Biltegiratutako prozedura berri bat sortzean, ez dago fitxategi-izen zuzena eskuz idatzi beharrik. Nahikoa da fitxategiak luzapena izatea .sql. Deialdiaren ostean deployDump errorearen testuak izen zuzena edukiko du, fitxategiari izena aldatzeko erabil daitekeena.

deployDump funtzio edo itzulera mota baten parametroak aldatzeko aukera ematen du ekintza gehigarririk gabe, ikuspegi klasikoarekin, berriz,
lehenik exekutatu DROP FUNCTION, eta orduan bakarrik CREATE OR REPLACE FUNCTION.

Zoritxarrez, badira egoera batzuk non deployDump ezin dira aldaketak automatikoki aplikatu. Adibidez, gutxienez abiarazle batek erabiltzen duen abiarazte-funtzioa kentzen bada. Horrelako egoerak eskuz konpontzen dira migrazio fitxategiak erabiliz.

Biltegiratutako prozeduretako aldaketak migratzeaz arduratzen bazara eskema-jasotzailea, orduan migrazio fitxategiak erabili behar dira egiturako beste aldaketa batzuk transferitzeko. Adibidez, migrazioekin lan egiteko liburutegi ona da doktrina/migrazioak.

Migrazioak martxan jarri aurretik aplikatu behar dira deployDump. Horri esker, egituran aldaketa guztiak egin ditzakezu eta egoera problematikoak konpontzeko, gordetako prozeduren aldaketak gero arazorik gabe transferitzeko.

Migrazioekin lan egitea zehatzago deskribatuko da hurrengo ataletan.

Nola antolatu hainbat garatzailek proiektu batean lan paraleloaren prozesua

Beharrezkoa da datu-basea erabat hasieratzeko script bat sortzea, garatzaileak bere lan-makinan abiaraziko duena, tokiko datu-basearen egitura VCS-n gordetako zabortegiarekin bat etorriz. Modurik errazena datu-base lokalaren hasiera 3 urratsetan banatzea da:

1. Deituko den oinarrizko egitura duen fitxategi bat inportatu adibidez. base.sql
2. Migrazioak aplikatzea
3. deiaren deployDump

base.sql migrazioak aplikatzen eta exekutatzen diren abiapuntua da deployDumpHau da, base.sql + миграции + deployDump = актуальная структура БД. Erabilgarritasuna erabiliz fitxategi hori sor dezakezu pg_dump. Erabiliak base.sql datu-basea hutsetik hastean soilik.

Dei diezaiogun scriptari datu-base osoa hasieratzeko refresh.sh. Lan-fluxua honelakoa izan daiteke:

1. Garatzailea bere ingurunean abiarazten da refresh.sh eta uneko datu-basearen egitura lortzen du
2. Garatzailea esku artean dagoen zereginean hasten da lanean, tokiko datu-basea aldatuz funtzionaltasun berriaren beharrei erantzuteko (ALTER TABLE ... ADD COLUMN etab)
3. Ataza amaitu ondoren, garatzaileak funtzioari deitzen dio saveDumpVCS-n datu-basean egindako aldaketak konprometitzeko
4. Garatzaileen berrabiaraztea refresh.sh, gero verifyDumphorrek orain migrazioan sartu beharreko aldaketen zerrenda erakusten du
5. Garatzaileak egitura-aldaketa guztiak migrazio fitxategira transferitzen ditu, berriro exekutatzen ditu refresh.sh и verifyDump, eta, migrazioa behar bezala konpilatzen bada, verifyDump ez du desberdintasunik erakutsiko tokiko datu-basearen eta gordetako iraulketaren artean

Goian deskribatutako prozesua gitflow printzipioekin bateragarria da. VCSko adar bakoitzak zabortegiaren bertsio propioa izango du, eta adarrak batzean, zabortegiak bateratuko dira. Kasu gehienetan, bateratze baten ondoren ez da ekintza gehigarririk egin behar, baina adar ezberdinetan aldaketak egin badira, adibidez, mahai berean, gatazka bat sor daiteke.

Har dezagun gatazka egoera bat adibide bat erabiliz: adar bat dago garatzea, zeinetatik bi adar adarkatzen dira: Ezaugarri1 и Ezaugarri2, gatazkarik ez dutenak garatzea, baina gatazkak dituzte elkarren artean. Eginkizuna bi adarrak bateratzea da garatzea. Kasu honetarako, lehenik eta behin adarren bat bateratzea gomendatzen da garatzeaeta gero batu garatzea gainerako adarrera, gainerako adarrean gatazkak ebatzi eta, ondoren, azken adarra bateratuz garatzea. Gatazkak konpontzeko fasean, baliteke migrazio-fitxategia azken adarrean konpondu behar izatea, bat-egiteen emaitzak biltzen dituen azken iraulketarekin bat egin dezan.

Nola zabaldu datu-basearen egituran aldaketa gehiago produkzio-ingurunean modu seguruan

VCS-en uneko datu-basearen egituraren iraulketa egoteari esker, ekoizpen-datu-baseak behar den egitura betetzen duen egiaztatzea posible egiten da. Honek garatzaileek nahi zituzten aldaketa guztiak ekoizpen-oinarrira arrakastaz transferitu zirela ziurtatzen du.

Bezala DDL PostgreSQL-n da transakzionalak, hurrengo inplementazio-agindua betetzea gomendatzen da, ustekabeko akatsen bat izanez gero, "minik gabe" exekutatu ahal izateko ROLLBACK:

1. Hasi transakzioa
2. Egin migrazio guztiak transakzio batean
3. Transakzio berean, exekutatu deployDump
4. Transakzioa osatu gabe, exekutatu verifyDump. Akatsik ez badago, exekutatu COMMIT. Akatsak badaude, exekutatu ROLLBACK

Urrats hauek aplikazioak hedatzeko dauden planteamenduetan erraz integra daitezke, zero geldialdi-denbora barne.

Ondorioa

Goian deskribatutako metodoei esker, "PHP + PostgreSQL" proiektuetatik errendimendu maximoa ateratzea posible da, garapen erosotasun txiki samarra sakrifikatuz, aplikazio-kode nagusian negozio-logika guztia ezartzearen aldean. Gainera, datuen tratamendua PL/pgSQL askotan gardenagoa dirudi eta PHPn idatzitako funtzionalitate bera baino kode gutxiago behar du.

Iturria: www.habr.com