Šio straipsnio tikslas – panaudoti bibliotekos pavyzdį schemos prižiūrėtojas parodyti įrankius, kurie gali žymiai supaprastinti duomenų bazių kūrimo procesą PHP projektuose naudojant PostgreSQL DBVS.

Šiame straipsnyje pateikta informacija visų pirma bus naudinga kūrėjams, kurie nori maksimaliai išnaudoti PostgreSQL galimybes, tačiau susiduria su problemomis išlaikant verslo logiką duomenų bazėje.

Šiame straipsnyje nebus aprašyti verslo logikos saugojimo duomenų bazėje pranašumai ar trūkumai. Daroma prielaida, kad pasirinkimą jau padarė skaitytojas.

Bus svarstomi šie klausimai:

1. Kokia forma duomenų bazės struktūros iškeltuvas turi būti saugomas versijų valdymo sistemoje (toliau – VCS)
2. Kaip sekti duomenų bazės struktūros pokyčius išsaugojus iškeltą
3. Kaip perkelti duomenų bazės struktūros pakeitimus į kitas aplinkas be konfliktų ir milžiniškų migracijos failų
4. Kaip organizuoti kelių kūrėjų lygiagrečio darbo su projektu procesą
5. Kaip saugiai įdiegti daugiau duomenų bazės struktūros pakeitimų gamybos aplinkoje
   

   SchemaKeeper skirtas darbui su saugomomis procedūromis, parašytomis kalba PL/pgSQL. Bandymai su kitomis kalbomis nebuvo atlikti, todėl naudojimas gali būti ne toks veiksmingas arba gali būti neįmanomas.

Kaip saugoti duomenų bazės struktūros iškeltą VCS

biblioteka schemos prižiūrėtojas suteikia funkciją saveDump, kuri išsaugo visų duomenų bazės objektų struktūrą kaip atskirus tekstinius failus. Išvestis yra katalogas, kuriame yra duomenų bazės struktūra, suskirstyta į sugrupuotus failus, kuriuos galima lengvai įtraukti į VCS.

Pažiūrėkime, kaip konvertuoti objektus iš duomenų bazės į failus, naudodami kelis pavyzdžius:

Objekto tipas
Schema
Pavadinimas
Santykinis kelias į failą

lentelė
visuomenės
sąskaitos
./public/tables/accounts.txt

Išsaugota procedūra
visuomenės
auth (hash bigint)
./public/functions/auth(int8).sql

Įvadas
internetu
tarifai
./booking/views/tariffs.txt

Failų turinys yra tekstinis konkretaus duomenų bazės objekto struktūros vaizdas. Pavyzdžiui, saugomų procedūrų atveju failo turinys bus visas saugomos procedūros apibrėžimas, pradedant nuo bloko CREATE OR REPLACE FUNCTION.

Kaip matyti iš aukščiau esančios lentelės, kelias į failą saugo informaciją apie objekto tipą, schemą ir pavadinimą. Šis metodas palengvina duomenų bazės pakeitimų iškelties ir kodo peržiūrą.

pratęsimas .sql failams su saugomų procedūrų šaltinio kodu pasirinkta, kad IDE automatiškai pateiktų įrankius sąveikai su duomenų baze, kai failas atidaromas.

Kaip sekti duomenų bazės struktūros pokyčius išsaugojus iškeltą

Išsaugodami dabartinės duomenų bazės struktūros iškeltą VCS, gauname galimybę patikrinti, ar duomenų bazės struktūroje buvo atlikti pakeitimai po to, kai buvo sukurta iškeltinė. Bibliotekoje schemos prižiūrėtojas duomenų bazės struktūros pokyčiams aptikti suteikiama funkcija verifyDump, kuris grąžina informaciją apie skirtumus be šalutinio poveikio.

Alternatyvus būdas patikrinti yra dar kartą iškviesti funkciją saveDump, nurodydami tą patį katalogą, ir patikrinkite VCS, ar nėra pakeitimų. Kadangi visi objektai iš duomenų bazės išsaugomi atskiruose failuose, VCS rodys tik pakeistus objektus.
Pagrindinis šio metodo trūkumas yra būtinybė perrašyti failus, kad būtų galima pamatyti pakeitimus.

Kaip perkelti duomenų bazės struktūros pakeitimus į kitas aplinkas be konfliktų ir milžiniškų migracijos failų

Dėl funkcijos deployDump Išsaugomų procedūrų šaltinio kodą galima redaguoti lygiai taip pat, kaip ir įprastą programos šaltinio kodą. Galite pridėti / ištrinti naujas saugomo procedūros kodo eilutes ir nedelsdami perkelti versijos valdymo pakeitimus arba sukurti / ištrinti saugomas procedūras sukurdami / ištrynę atitinkamus failus iškelties kataloge.

Pavyzdžiui, sukurti naują saugomą procedūrą schemoje public tiesiog sukurkite naują failą su plėtiniu .sql kataloge public/functions, įdėkite į jį saugomos procedūros šaltinio kodą, įskaitant bloką CREATE OR REPLACE FUNCTION, tada iškvieskite funkciją deployDump. Išsaugotos procedūros keitimas ir ištrynimas vyksta taip pat. Taigi kodas vienu metu patenka ir į VCS, ir į duomenų bazę.

Jei bet kurios saugomos procedūros šaltinio kode atsiranda klaida arba failo ir saugomos procedūros pavadinimų neatitikimas, tada deployDump nepavyks, bus rodomas klaidos tekstas. Saugomų procedūrų neatitikimas tarp iškelties ir dabartinės duomenų bazės yra neįmanomas naudojant deployDump.

Kuriant naują saugomą procedūrą, nereikia rankiniu būdu įvesti teisingo failo pavadinimo. Pakanka, kad failas turėtų plėtinį .sql. Po skambučio deployDump klaidos tekste bus nurodytas teisingas pavadinimas, kuris gali būti naudojamas failui pervardyti.

deployDump leidžia keisti funkcijos ar grąžinimo tipo parametrus be papildomų veiksmų, o naudojant klasikinį metodą, tai tektų
vykdyti pirmas DROP FUNCTION, ir tik tada CREATE OR REPLACE FUNCTION.

Deja, yra situacijų, kai deployDump negalima automatiškai pritaikyti pakeitimų. Pavyzdžiui, jei pašalinama aktyviklio funkcija, kurią naudoja bent vienas paleidiklis. Tokios situacijos išsprendžiamos rankiniu būdu naudojant perkėlimo failus.

Jei esate atsakingas už saugomų procedūrų pakeitimų perkėlimą schemos prižiūrėtojas, tada perkėlimo failai turi būti naudojami kitiems struktūros pakeitimams perkelti. Pavyzdžiui, gera biblioteka darbui su perkėlimu yra doktrina/migracijos.

Perkėlimai turi būti pritaikyti prieš paleidžiant deployDump. Tai leidžia atlikti visus struktūros pakeitimus ir išspręsti problemines situacijas, kad vėliau saugomų procedūrų pakeitimai būtų perkelti be problemų.

Darbas su perkėlimu bus išsamiau aprašytas tolesniuose skyriuose.

Kaip organizuoti kelių kūrėjų lygiagrečio darbo su projektu procesą

Būtina sukurti scenarijų, skirtą visiškam duomenų bazės inicijavimui, kurį kūrėjas paleis savo darbo mašinoje, suderindamas vietinės duomenų bazės struktūrą su VCS išsaugotu iškrovimu. Lengviausias būdas yra padalinti vietinės duomenų bazės inicijavimą į 3 veiksmus:

1. Importuokite pagrindinės struktūros failą, kuris bus vadinamas pvz. base.sql
2. Migracijų taikymas
3. Вызов deployDump

base.sql yra pradinis taškas, ant kurio taikomos ir vykdomos perkėlimai deployDumpTai reiškia, kad base.sql + миграции + deployDump = актуальная структура БД. Tokį failą galite sukurti naudodami įrankį pg_dump. Naudota base.sql išimtinai inicijuojant duomenų bazę nuo nulio.

Iškvieskime scenarijų, kad būtų galima visiškai inicijuoti duomenų bazę refresh.sh. Darbo eiga gali atrodyti taip:

1. Kūrėjas paleidžia savo aplinkoje refresh.sh ir gauna dabartinę duomenų bazės struktūrą
2. Kūrėjas pradeda dirbti su atliekama užduotimi, pakeisdamas vietinę duomenų bazę, kad atitiktų naujos funkcijos poreikius (ALTER TABLE ... ADD COLUMN ir tt)
3. Atlikęs užduotį, kūrėjas iškviečia funkciją saveDumpatlikti VCS duomenų bazės pakeitimus
4. Kūrėjo paleidimas iš naujo refresh.sh, tada verifyDumpkuriame dabar rodomas pakeitimų, kuriuos reikia įtraukti į perkėlimą, sąrašas
5. Kūrėjas perkelia visus struktūros pakeitimus į perkėlimo failą, paleidžiamas iš naujo refresh.sh и verifyDumpir, jei perkėlimas sudarytas teisingai, verifyDump nerodys skirtumų tarp vietinės duomenų bazės ir išsaugotos iškelties

Aukščiau aprašytas procesas yra suderinamas su gitflow principais. Kiekviename VCS atšaka turės savo sąvartyno versiją, o sujungiant šakas, sąvartynai bus sujungti. Daugeliu atvejų po sujungimo nereikia imtis jokių papildomų veiksmų, tačiau jei buvo atlikti pakeitimai skirtingose ​​šakose, pavyzdžiui, toje pačioje lentelėje, gali kilti konfliktas.

Panagrinėkime konfliktinę situaciją naudodami pavyzdį: yra filialas plėtoti, iš kurios išsišakoja dvi šakos: funkcija1 и funkcija2, kurie neturi konfliktų su plėtoti, bet turi konfliktų vienas su kitu. Užduotis yra sujungti abi šakas į plėtoti. Tokiu atveju pirmiausia rekomenduojama sujungti vieną iš šakų plėtotiir tada sujungti plėtoti į likusią šaką, išsprendžiant konfliktus likusioje šakoje, o tada sujungiant paskutinę šaką į plėtoti. Konflikto sprendimo etape gali tekti pataisyti perkėlimo failą paskutinėje šakoje, kad jis atitiktų galutinį išrašymą, kuriame yra sujungimų rezultatai.

Kaip saugiai įdiegti daugiau duomenų bazės struktūros pakeitimų gamybos aplinkoje

Dėl VCS esamos duomenų bazės struktūros išvarčio galima patikrinti, ar gamybos duomenų bazė tiksliai atitinka reikiamą struktūrą. Tai užtikrina, kad visi kūrėjų numatyti pakeitimai buvo sėkmingai perkelti į gamybinę bazę.

Kaip DDL PostgreSQL yra sandorio, rekomenduojama laikytis šios diegimo tvarkos, kad netikėtos klaidos atveju galėtumėte „neskausmingai“ atlikti ROLLBACK:

1. Pradėti sandorį
2. Atlikite visus perkėlimus per operaciją
3. Vykdykite tą pačią operaciją deployDump
4. Nebaigus operacijos, įvykdykite verifyDump. Jei klaidų nėra, paleiskite COMMIT. Jei yra klaidų, paleiskite ROLLBACK

Šiuos veiksmus galima lengvai integruoti į esamus taikomųjų programų diegimo metodus, įskaitant nulinę prastovos trukmę.

išvada

Aukščiau aprašytų metodų dėka iš „PHP + PostgreSQL“ projektų galima išspausti maksimalų našumą, tuo pačiu paaukojant palyginti nedaug kūrimo patogumo, palyginti su visos verslo logikos įgyvendinimu pagrindiniame programos kode. Be to, duomenų apdorojimas PL/pgSQL dažnai atrodo skaidresnis ir reikalauja mažiau kodo nei ta pati funkcija, parašyta PHP.

Šaltinis: www.habr.com