Selle artikli eesmärk on kasutada raamatukogu näidet skeemipidaja näidata tööriistu, mis võivad märkimisväärselt lihtsustada andmebaaside arendamise protsessi PHP-projektides, kasutades PostgreSQL DBMS-i.

Selle artikli teave on ennekõike kasulik arendajatele, kes soovivad PostgreSQL-i võimalusi maksimaalselt ära kasutada, kuid kellel on probleeme andmebaasi paigutatud äriloogika säilitamisega.

Artiklis ei kirjeldata äriloogika andmebaasis talletamise eeliseid ega puudusi. Eeldatakse, et valiku on lugeja juba teinud.

Arvesse võetakse järgmised küsimused:

1. Millisel kujul tuleks versioonihaldussüsteemis (edaspidi VCS) salvestada andmebaasi struktuuri tõmmis?
2. Kuidas jälgida muudatusi andmebaasi struktuuris pärast tõmmise salvestamist
3. Kuidas andmebaasi struktuuri muudatusi konfliktide ja hiiglaslike migratsioonifailideta teistesse keskkondadesse üle kanda
4. Kuidas korraldada mitme arendaja paralleelset tööd projektiga
5. Kuidas ohutult juurutada rohkem muudatusi andmebaasi struktuuris tootmiskeskkonda
   

   SchemaKeeper mõeldud töötamiseks keeles kirjutatud salvestatud protseduuridega PL/pgSQL. Teiste keeltega testimist ei ole läbi viidud, seega ei pruugi kasutamine olla nii tõhus või võimatu.

Kuidas salvestada VCS-is andmebaasi struktuuri tõmmist

raamatukogu skeemipidaja pakub funktsiooni saveDump, mis salvestab kõigi objektide struktuuri andmebaasist eraldi tekstifailidena. Väljund on andmebaasi struktuuri sisaldav kataloog, mis on jagatud rühmitatud failideks, mida saab hõlpsasti VCS-i lisada.

Vaatame mitme näite abil objektide teisendamist andmebaasist failideks:

Objekti tüüp
Kava
nimi
Faili suhteline tee

tabel
avalik
raamatupidamise
./public/tables/accounts.txt

Salvestatud protseduur
avalik
auth (hash bigint)
./public/functions/auth(int8).sql

Sissejuhatus
broneerimine
tariifid
./booking/views/tariffs.txt

Failide sisu kujutab endast konkreetse andmebaasiobjekti struktuuri tekstilist esitust. Näiteks salvestatud protseduuride puhul on faili sisu salvestatud protseduuri täielik määratlus, alustades plokist CREATE OR REPLACE FUNCTION.

Nagu ülaltoodud tabelist näha, salvestab faili tee teavet objekti tüübi, skeemi ja nimetuse kohta. See lähenemine hõlbustab andmebaasis tehtud muudatuste dump- ja koodiülevaatuses navigeerimist.

laiendamine .sql salvestatud protseduuride lähtekoodiga failide puhul valiti see nii, et IDE pakub faili avamisel automaatselt tööriistu andmebaasiga suhtlemiseks.

Kuidas jälgida muudatusi andmebaasi struktuuris pärast tõmmise salvestamist

Salvestades VCS-i praeguse andmebaasi struktuuri tõmmise, saame võimaluse kontrollida, kas andmebaasi struktuuris tehti pärast tõmmise loomist muudatusi. Raamatukogus skeemipidaja andmebaasi struktuuri muutuste tuvastamiseks on ette nähtud funktsioon verifyDump, mis tagastab teabe erinevuste kohta ilma kõrvalmõjudeta.

Alternatiivne viis kontrollimiseks on funktsiooni uuesti kutsumine saveDump, määrates sama kataloogi, ja kontrollige VCS-is muudatusi. Kuna kõik andmebaasi objektid salvestatakse eraldi failidesse, näitab VCS ainult muudetud objekte.
Selle meetodi peamiseks puuduseks on vajadus muudatuste nägemiseks failid üle kirjutada.

Kuidas andmebaasi struktuuri muudatusi konfliktide ja hiiglaslike migratsioonifailideta teistesse keskkondadesse üle kanda

Tänu funktsioonile deployDump Salvestatud protseduuride lähtekoodi saab redigeerida täpselt samamoodi nagu tavarakenduse lähtekoodi. Salvestatud protseduurikoodi saab lisada/kustutada uusi ridu ja koheselt lükata muudatused versioonihaldusse või salvestatud protseduure luua/kustutada, luues/kustutades vastavad failid dump kataloogis.

Näiteks uue salvestatud protseduuri loomiseks skeemis public lihtsalt looge uus fail laiendiga .sql kataloogis public/functions, asetage sellesse salvestatud protseduuri lähtekood, sealhulgas plokk CREATE OR REPLACE FUNCTION, seejärel helistage funktsioonile deployDump. Salvestatud protseduuri muutmine ja kustutamine toimub samal viisil. Seega läheb kood korraga nii VCS-i kui ka andmebaasi.

Kui mõne salvestatud protseduuri lähtekoodis ilmneb tõrge või faili ja salvestatud protseduuri nimede lahknevus, deployDump ebaõnnestub, kuvatakse veatekst. Salvestatud protseduuride mittevastavus väljavõtte ja praeguse andmebaasi vahel on kasutamisel võimatu deployDump.

Uue salvestatud protseduuri loomisel ei ole vaja õiget failinime käsitsi sisestada. Piisab, kui failil on laiend .sql. Peale kõnet deployDump veatekst sisaldab õiget nime, mida saab kasutada faili ümbernimetamiseks.

deployDump võimaldab teil muuta funktsiooni või tagastustüübi parameetreid ilma lisatoiminguteta, samas kui klassikalise lähenemise korral peaksite seda tegema
esmalt teostada DROP FUNCTION, ja alles siis CREATE OR REPLACE FUNCTION.

Kahjuks on olukordi, kus deployDump ei saa muudatusi automaatselt rakendada. Näiteks kui eemaldatakse päästikufunktsioon, mida kasutab vähemalt üks päästik. Sellised olukorrad lahendatakse käsitsi migratsioonifailide abil.

Kui vastutate salvestatud protseduuridesse muudatuste üleviimise eest skeemipidaja, siis tuleb struktuuri muude muudatuste ülekandmiseks kasutada migratsioonifaile. Näiteks on hea raamatukogu migratsiooniga töötamiseks doktriin/ränded.

Migratsioonid tuleb rakendada enne käivitamist deployDump. See võimaldab teil teha kõik muudatused struktuuris ja lahendada probleemsed olukorrad, nii et salvestatud protseduuride muudatused kantakse hiljem probleemideta üle.

Tööd migratsiooniga kirjeldatakse üksikasjalikumalt järgmistes jaotistes.

Kuidas korraldada mitme arendaja paralleelset tööd projektiga

Andmebaasi täielikuks initsialiseerimiseks on vaja luua skript, mille arendaja käivitab oma töömasinas, viies kohaliku andmebaasi struktuuri kooskõlla VCS-i salvestatud dumpiga. Lihtsaim viis on jagada kohaliku andmebaasi lähtestamine kolmeks etapiks:

1. Importige põhistruktuuriga fail, mida hakatakse kutsuma nt. base.sql
2. Migratsioonide rakendamine
3. Väljakutse deployDump

base.sql on lähtepunkt, mille peale migratsioone rakendatakse ja teostatakse deployDumpSee tähendab, et base.sql + миграции + deployDump = актуальная структура БД. Sellise faili saate luua utiliidi abil pg_dump. Kasutatud base.sql eranditult andmebaasi nullist lähtestamisel.

Kutsume skripti täielikuks andmebaasi initsialiseerimiseks refresh.sh. Töövoog võib välja näha selline:

1. Arendaja käivitab oma keskkonnas refresh.sh ja saab praeguse andmebaasi struktuuri
2. Arendaja alustab tööd käsiloleva ülesandega, muutes kohalikku andmebaasi, et see vastaks uue funktsiooni vajadustele (ALTER TABLE ... ADD COLUMN jne)
3. Pärast ülesande täitmist kutsub arendaja funktsiooni välja saveDumpVCS-i andmebaasis tehtud muudatuste tegemiseks
4. Arendaja taaskäivitamine refresh.shSiis verifyDumpmis näitab nüüd migratsiooni kaasatavate muudatuste loendit
5. Arendaja kannab kõik struktuurimuudatused üle migratsioonifaili ja käivitab uuesti refresh.sh и verifyDumpja kui migratsioon on õigesti koostatud, verifyDump ei näita erinevusi kohaliku andmebaasi ja salvestatud väljavõtte vahel

Ülalkirjeldatud protsess ühildub gitflow põhimõtetega. Iga VCS-i haru sisaldab oma prügikasti versiooni ja harude ühendamisel ühendatakse prügimäed. Enamasti pole pärast liitmist vaja täiendavaid toiminguid teha, kuid kui erinevates harudes tehti muudatusi, näiteks samas tabelis, võib tekkida konflikt.

Vaatleme konfliktsituatsiooni näite varal: filiaal on olemas arendama, millest hargneb kaks haru: funktsioon1 и funktsioon2, millega pole vastuolus arendama, kuid neil on omavahel konflikte. Ülesanne on ühendada mõlemad harud omavahel arendama. Sel juhul on soovitatav kõigepealt ühendada üks harudest arendamaja seejärel liita arendama ülejäänud harule, lahendades ülejäänud harus olevad konfliktid ja seejärel liites viimase haru arendama. Konflikti lahendamise etapis peate võib-olla parandama migratsioonifaili viimases harus, nii et see ühtiks lõpliku väljavõttega, mis sisaldab liitmiste tulemusi.

Kuidas ohutult juurutada rohkem muudatusi andmebaasi struktuuris tootmiskeskkonda

Tänu VCS-is oleva praeguse andmebaasi struktuuri prügila olemasolule on võimalik kontrollida tootmisandmebaasi täpset vastavust nõutavale struktuurile. See tagab, et kõik muudatused, mida arendajad kavatsesid, viidi edukalt üle tootmisbaasi.

Kui DDL PostgreSQL-is on tehinguline, on soovitatav järgida järgmist juurutuskäsku, et ootamatu tõrke korral saaksid "valutult" käivitada ROLLBACK:

1. Alusta tehingut
2. Tehke tehingus kõik migratsioonid
3. Samas tehingus täitke deployDump
4. Tehingut lõpule viimata täitke verifyDump. Kui vigu pole, käivitage COMMIT. Kui on vigu, käivitage ROLLBACK

Neid samme saab hõlpsasti integreerida olemasolevatesse rakenduste juurutamise lähenemisviisidesse, sealhulgas nullseisuaega.

Järeldus

Tänu ülalkirjeldatud meetoditele on võimalik “PHP + PostgreSQL” projektidest välja pigistada maksimaalne jõudlus, ohverdades samas suhteliselt vähe arendusmugavust võrreldes kogu äriloogika juurutamisega põhirakenduse koodis. Lisaks toimub andmetöötlus sisse PL/pgSQL sageli näeb välja läbipaistvam ja nõuab vähem koodi kui samad funktsioonid, mis on kirjutatud PHP-s.

Allikas: www.habr.com