La celo de ĉi tiu artikolo estas uzi la ekzemplon de biblioteko skemo-gardanto montri ilojn kiuj povas signife simpligi la procezon de evoluigado de datumbazoj ene de PHP-projektoj uzante la PostgreSQL DBMS.

La informoj de ĉi tiu artikolo estos, antaŭ ĉio, utilaj al programistoj, kiuj volas utiligi la plej multajn kapablojn de PostgreSQL, sed alfrontas problemojn pri konservado de komerca logiko metita en la datumbazon.

Ĉi tiu artikolo ne priskribos la avantaĝojn aŭ malavantaĝojn de stokado de komerca logiko en datumbazo. Oni supozas, ke la elekto jam estas farita de la leganto.

La sekvaj demandoj estos konsiderataj:

1. En kia formo devus datumbaza strukturrubejo esti stokita en versio-kontrolsistemo (ĉi-poste referita kiel VCS)
2. Kiel spuri ŝanĝojn en la datumbaza strukturo post konservado de rubejo
3. Kiel transdoni ŝanĝojn en la datumbaza strukturo al aliaj medioj sen konfliktoj kaj gigantaj migraj dosieroj
4. Kiel organizi la procezon de paralela laboro en projekto de pluraj programistoj
5. Kiel sekure deploji pli da ŝanĝoj en la datumbaza strukturo al produktadmedio
   

   SchemaKeeper desegnita por labori kun stokitaj proceduroj skribitaj en la lingvo PL/pgSQL. Testado kun aliaj lingvoj ne estis farita, do uzo eble ne estas tiel efika aŭ eble ne eblas.

Kiel stoki datumbazan strukturrujon en VCS

biblioteko skemo-gardanto provizas funkcion saveDump, kiu konservas la strukturon de ĉiuj objektoj el la datumbazo kiel apartaj tekstaj dosieroj. La eligo estas dosierujo enhavanta la datumbazan strukturon, dividitan en grupigitajn dosierojn, kiuj povas esti facile aldonitaj al VCS.

Ni rigardu konverti objektojn de datumbazo en dosierojn uzante plurajn ekzemplojn:

Objekta tipo
Skemo
nomo
Relativa vojo al dosiero

tablo
publikajn
kontoj
./public/tables/accounts.txt

Stokita proceduro
publikajn
aŭth (hash bigint)
./public/functions/auth(int8).sql

Enkonduko
mendo
tarifoj
./booking/views/tariffs.txt

La enhavo de la dosieroj estas teksta reprezentado de la strukturo de specifa datumbaza objekto. Ekzemple, por stokitaj proceduroj, la enhavo de la dosiero estos la plena difino de la stokita proceduro, komencante per la bloko CREATE OR REPLACE FUNCTION.

Kiel videblas de la supra tabelo, la vojo al la dosiero konservas informojn pri la tipo, skemo kaj nomo de la objekto. Ĉi tiu aliro faciligas navigi tra la rubejo kaj koda revizio de ŝanĝoj en la datumbazo.

pligrandigo .sql por dosieroj kun stokita proceda fontkodo, tio estis elektita tiel ke la IDE aŭtomate disponigas ilojn por interagado kun la datumbazo kiam la dosiero estas malfermita.

Kiel spuri ŝanĝojn en la datumbaza strukturo post konservado de rubejo

Konservante rubejon de la nuna datumbaza strukturo en VCS, ni ricevas la ŝancon kontroli ĉu ŝanĝoj estis faritaj al la datumbaza strukturo post kiam la rubejo estis kreita. En biblioteko skemo-gardanto por detekti ŝanĝojn en la datumbaza strukturo, funkcio estas disponigita verifyDump, kiu resendas informojn pri la diferencoj sen kromefikoj.

Alternativa maniero por kontroli estas voki la funkcion denove saveDump, specifigante la saman dosierujon, kaj kontrolu en VCS por ŝanĝoj. Ĉar ĉiuj objektoj el la datumbazo estas konservitaj en apartaj dosieroj, VCS nur montros ŝanĝitajn objektojn.
La ĉefa malavantaĝo de ĉi tiu metodo estas la bezono anstataŭigi dosierojn por vidi la ŝanĝojn.

Kiel transdoni ŝanĝojn en la datumbaza strukturo al aliaj medioj sen konfliktoj kaj gigantaj migraj dosieroj

Danke al la funkcio deployDump La fontkodo de stokitaj proceduroj povas esti redaktita ekzakte same kiel la regula aplika fontkodo. Vi povas aldoni/forviŝi novajn liniojn en stokita procedokodo kaj tuj puŝi ŝanĝojn al versiokontrolo, aŭ krei/forviŝi konservitajn procedurojn kreante/forigante la respondajn dosierojn en la rubujo dosierujo.

Ekzemple, krei novan stokitan proceduron en skemo public simple kreu novan dosieron kun la etendaĵo .sql en la dosierujo public/functions, metu la fontkodon de la konservita proceduro en ĝi, inkluzive de la bloko CREATE OR REPLACE FUNCTION, tiam voku la funkcion deployDump. Modifi kaj forigo de stokita proceduro okazas sammaniere. Tiel, la kodo eniras kaj la VCS kaj la datumbazon samtempe.

Se eraro aperas en la fontkodo de iu konservita proceduro, aŭ diferenco inter la nomoj de la dosiero kaj la stokita proceduro, tiam deployDump malsukcesos, montrante erartekston. Miskongruo de stokitaj proceduroj inter la rubejo kaj la nuna datumbazo estas neebla dum uzado deployDump.

Kreante novan konservitan proceduron, ne necesas permane enigi la ĝustan dosiernomon. Sufiĉas, ke la dosiero havu la etendon .sql. Post la voko deployDump la erarteksto enhavos la ĝustan nomon, kiu povas esti uzata por renomi la dosieron.

deployDump permesas ŝanĝi la parametrojn de funkcio aŭ revena tipo sen aldonaj agoj, dum kun la klasika aliro vi devus
unue ekzekuti DROP FUNCTION, kaj nur tiam CREATE OR REPLACE FUNCTION.

Bedaŭrinde, estas iuj situacioj kie deployDump ne povas aŭtomate apliki ŝanĝojn. Ekzemple, se ellasilfunkcio kiu estas uzata de almenaŭ unu ellasilo estas forigita. Tiaj situacioj estas solvitaj permane uzante migrajn dosierojn.

Se vi respondecas pri migrado de ŝanĝoj al konservitaj proceduroj skemo-gardanto, tiam migraj dosieroj devas esti uzataj por transdoni aliajn ŝanĝojn en la strukturo. Ekzemple, bona biblioteko por labori kun migradoj estas doktrino/migradoj.

Migradoj devas esti aplikataj antaŭ lanĉo deployDump. Ĉi tio ebligas al vi fari ĉiujn ŝanĝojn al la strukturo kaj solvi problemajn situaciojn por ke ŝanĝoj en stokitaj proceduroj poste estu translokigitaj sen problemoj.

Laborado kun migradoj estos priskribita pli detale en la sekvaj sekcioj.

Kiel organizi la procezon de paralela laboro en projekto de pluraj programistoj

Necesas krei skripton por la kompleta inicialigo de la datumbazo, kiu estos lanĉita de la programisto sur sia labormaŝino, alportante la strukturon de la loka datumbazo konforme al la rubejo konservita en VCS. La plej facila maniero estas dividi la inicialigon de la loka datumbazo en 3 paŝojn:

1. Importu dosieron kun baza strukturo, kiu nomos ekz. base.sql
2. Apliko de Migradoj
3. Defio deployDump

base.sql estas la deirpunkto super kiu migradoj estas aplikataj kaj efektivigitaj deployDumptio estas base.sql + миграции + deployDump = актуальная структура БД. Vi povas krei tian dosieron uzante la ilon pg_dump. Uzita base.sql ekskluzive dum pravalorigo de la datumbazo de nulo.

Ni voku la skripton por kompleta datumbaza inicialigo refresh.sh. La laborfluo povus aspekti jene:

1. La programisto lanĉas en sia medio refresh.sh kaj ricevas la nunan datumbazan strukturon
2. La programisto komencas labori pri la nuna tasko, modifante la lokan datumbazon por renkonti la bezonojn de la nova funkcieco (ALTER TABLE ... ADD COLUMN ktp)
3. Post plenumi la taskon, la programisto vokas la funkcion saveDumpfari ŝanĝojn faritajn al la datumbazo en VCS
4. Relanĉo de programistoj refresh.shtiam verifyDumpkiu nun montras liston de ŝanĝoj por inkluzivi en la migrado
5. La programisto transdonas ĉiujn strukturajn ŝanĝojn al la migra dosiero, denove funkcias refresh.sh и verifyDump, kaj, se la migrado estas kompilita ĝuste, verifyDump montros neniujn diferencojn inter la loka datumbazo kaj la konservita rubejo

La procezo priskribita supre estas kongrua kun gitflow-principoj. Ĉiu branĉo en la VCS enhavos sian propran version de la rubejo, kaj dum kunfandado de branĉoj, la rubejoj estos kunfanditaj. Plejofte, neniu kroma ago devas esti prenita post kunfandado, sed se ŝanĝoj estis faritaj sur malsamaj branĉoj, ekzemple al la sama tabelo, konflikto povas ekesti.

Ni konsideru konfliktan situacion uzante ekzemplon: estas branĉo evoluigi, el kiu disbranĉiĝas du branĉoj: trajto1 и trajto2, kiuj ne havas konfliktojn kun evoluigi, sed havas konfliktojn unu kun la alia. La tasko estas kunfandi ambaŭ branĉojn en evoluigi. Por ĉi tiu kazo, oni rekomendas unue kunfandi unu el la branĉoj en evoluigikaj poste kunfandi evoluigi al la restanta branĉo, solvante konfliktojn en la restanta branĉo, kaj tiam kunfandante la lastan branĉon en evoluigi. Dum la konflikta solva fazo, vi eble devos ripari la migradan dosieron en la lasta branĉo, por ke ĝi kongruu kun la fina rubejo, kiu inkluzivas la rezultojn de la kunfandaĵoj.

Kiel sekure deploji pli da ŝanĝoj en la datumbaza strukturo al produktadmedio

Danke al la ĉeesto de rubejo de la nuna datumbaza strukturo en VCS, eblas kontroli la produktan datumbazon por ĝusta konformeco al la bezonata strukturo. Ĉi tio certigas, ke ĉiuj ŝanĝoj, kiujn la programistoj celis, estis sukcese transdonitaj al la produktada bazo.

Ekde DDL en PostgreSQL estas transakcia, oni rekomendas aliĝi al la sekva disfalda ordo, por ke, en kazo de neatendita eraro, vi povu "sendolore" ekzekuti ROLLBACK:

1. Komencu transakcion
2. Faru ĉiujn migradojn en transakcio
3. En la sama transakcio, ekzekutu deployDump
4. Sen kompletigi la transakcion, ekzekutu verifyDump. Se ne estas eraroj, kuru COMMIT. Se estas eraroj, kuru ROLLBACK

Ĉi tiuj paŝoj povas esti facile integritaj en ekzistantajn alirojn al aplikaĵa deplojo, inkluzive de nul-malfunkcio.

konkludo

Danke al la supre priskribitaj metodoj, eblas elpremi maksimuman rendimenton el "PHP + PostgreSQL" projektoj, oferante relative malmulte da disvolva komforto kompare kun efektivigi la tutan komercan logikon en la ĉefa aplika kodo. Plie, prilaborado de datumoj en PL/pgSQL ofte aspektas pli travidebla kaj postulas malpli da kodo ol la sama funkcio skribita en PHP.

fonto: www.habr.com