Účelom tohto článku je použiť príklad knižnice správca schémy ukázať nástroje, ktoré môžu výrazne zjednodušiť proces vývoja databáz v rámci projektov PHP pomocou PostgreSQL DBMS.

Informácie z tohto článku budú v prvom rade užitočné pre vývojárov, ktorí chcú čo najlepšie využiť možnosti PostgreSQL, no čelia problémom s udržiavaním obchodnej logiky umiestnenej v databáze.

Tento článok nebude popisovať výhody alebo nevýhody ukladania obchodnej logiky v databáze. Predpokladá sa, že výber už urobil čitateľ.

Budú sa posudzovať tieto otázky:

1. V akej forme má byť uložený výpis štruktúry databázy v systéme správy verzií (ďalej len VCS)
2. Ako sledovať zmeny v štruktúre databázy po uložení výpisu
3. Ako preniesť zmeny v štruktúre databázy do iných prostredí bez konfliktov a obrovských migračných súborov
4. Ako zorganizovať proces paralelnej práce na projekte viacerými vývojármi
5. Ako bezpečne nasadiť viac zmien v štruktúre databázy do produkčného prostredia
   

   SchemaKeeper navrhnutý pre prácu s uloženými procedúrami napísanými v jazyku PL/pgSQL. Testovanie s inými jazykmi nebolo vykonané, takže používanie nemusí byť také efektívne alebo nemusí byť možné.

Ako uložiť výpis štruktúry databázy vo VCS

knižnica správca schémy poskytuje funkciu saveDump, ktorý uloží štruktúru všetkých objektov z databázy ako samostatné textové súbory. Výstupom je adresár obsahujúci štruktúru databázy, rozdelený do zoskupených súborov, ktoré možno jednoducho pridať do VCS.

Pozrime sa na prevod objektov z databázy na súbory pomocou niekoľkých príkladov:

Typ objektu
Schéma
názov
Relatívna cesta k súboru

stôl
verejnosť
účty
./public/tables/accounts.txt

Uložená procedúra
verejnosť
auth (hash bigint)
./public/functions/auth(int8).sql

idea
Rezervácia
tarify
./booking/views/tariffs.txt

Obsahom súborov je textová reprezentácia štruktúry konkrétneho databázového objektu. Napríklad pri uložených procedúrach bude obsahom súboru úplná definícia uloženej procedúry počnúc blokom CREATE OR REPLACE FUNCTION.

Ako je zrejmé z tabuľky vyššie, cesta k súboru uchováva informácie o type, schéme a názve objektu. Tento prístup uľahčuje navigáciu cez výpis a kontrolu kódu zmien v databáze.

predĺženie .sql pre súbory so zdrojovým kódom uloženej procedúry to bolo vybrané tak, že IDE automaticky poskytuje nástroje na interakciu s databázou pri otvorení súboru.

Ako sledovať zmeny v štruktúre databázy po uložení výpisu

Uložením výpisu aktuálnej štruktúry databázy vo VCS získame možnosť skontrolovať, či po vytvorení výpisu neboli vykonané zmeny v štruktúre databázy. V knižnici správca schémy na zistenie zmien v štruktúre databázy je poskytnutá funkcia verifyDump, ktorý vracia informácie o rozdieloch bez vedľajších účinkov.

Alternatívnym spôsobom kontroly je opätovné zavolanie funkcie saveDumps uvedením rovnakého adresára a skontrolujte zmeny vo VCS. Keďže všetky objekty z databázy sú uložené v samostatných súboroch, VCS zobrazí iba zmenené objekty.
Hlavnou nevýhodou tejto metódy je potreba prepísať súbory, aby bolo možné vidieť zmeny.

Ako preniesť zmeny v štruktúre databázy do iných prostredí bez konfliktov a obrovských migračných súborov

Vďaka funkcii deployDump Zdrojový kód uložených procedúr je možné upravovať presne rovnakým spôsobom ako zdrojový kód bežnej aplikácie. Môžete pridať/vymazať nové riadky v kóde uloženej procedúry a okamžite vložiť zmeny do správy verzií alebo vytvoriť/vymazať uložené procedúry vytvorením/odstránením príslušných súborov v adresári výpisu.

Napríklad na vytvorenie novej uloženej procedúry v schéme public stačí vytvoriť nový súbor s príponou .sql v adresári public/functions, umiestnite do nej zdrojový kód uloženej procedúry vrátane bloku CREATE OR REPLACE FUNCTION, potom zavolajte funkciu deployDump. Úprava a odstránenie uloženej procedúry prebieha rovnakým spôsobom. Kód teda ide do VCS aj do databázy súčasne.

Ak sa v zdrojovom kóde akejkoľvek uloženej procedúry objaví chyba alebo nezrovnalosti medzi názvami súboru a uloženej procedúry, potom deployDump zlyhá a zobrazí sa chybový text. Nesúlad uložených procedúr medzi výpisom a aktuálnou databázou je pri použití nemožný deployDump.

Pri vytváraní novej uloženej procedúry nie je potrebné manuálne zadávať správny názov súboru. Stačí, aby mal súbor príponu .sql. Po hovore deployDump chybový text bude obsahovať správny názov, ktorý možno použiť na premenovanie súboru.

deployDump umožňuje zmeniť parametre funkcie alebo návratového typu bez dodatočných akcií, zatiaľ čo pri klasickom prístupe by ste to museli urobiť
vykonať ako prvý DROP FUNCTIONa až potom CREATE OR REPLACE FUNCTION.

Bohužiaľ, existujú situácie, kedy deployDump nedokáže automaticky aplikovať zmeny. Napríklad, ak je odstránená funkcia spúšťača, ktorú používa aspoň jeden spúšťač. Takéto situácie sa riešia manuálne pomocou migračných súborov.

Ak ste zodpovedný za migráciu zmien uložených procedúr správca schémy, potom je potrebné použiť migračné súbory na prenos ďalších zmien v štruktúre. Napríklad dobrá knižnica na prácu s migráciami je doktrína/migrácie.

Migrácie musia byť použité pred spustením deployDump. To umožňuje vykonávať všetky zmeny v štruktúre a riešiť problematické situácie tak, aby sa zmeny v uložených procedúrach následne bez problémov preniesli.

Práca s migráciami bude podrobnejšie popísaná v nasledujúcich častiach.

Ako zorganizovať proces paralelnej práce na projekte viacerými vývojármi

Pre kompletnú inicializáciu databázy je potrebné vytvoriť skript, ktorý spustí vývojár na svojom pracovnom stroji, čím uvedie štruktúru lokálnej databázy do súladu s výpisom uloženým vo VCS. Najjednoduchším spôsobom je rozdeliť inicializáciu lokálnej databázy do 3 krokov:

1. Importujte súbor so základnou štruktúrou, ktorá sa bude volať napr. base.sql
2. Uplatňovanie migrácií
3. volanie deployDump

base.sql je počiatočný bod, nad ktorým sa aplikujú a vykonajú migrácie deployDumpTo znamená, že base.sql + миграции + deployDump = актуальная структура БД. Takýto súbor môžete vytvoriť pomocou pomôcky pg_dump. Použité base.sql výhradne pri inicializácii databázy od začiatku.

Zavolajme skript na kompletnú inicializáciu databázy refresh.sh. Pracovný postup môže vyzerať takto:

1. Vývojár sa spustí vo svojom prostredí refresh.sh a získa aktuálnu štruktúru databázy
2. Vývojár začne pracovať na danej úlohe a upraví lokálnu databázu tak, aby vyhovovala potrebám novej funkcionality (ALTER TABLE ... ADD COLUMN atď)
3. Po dokončení úlohy vývojár zavolá funkciu saveDumpna potvrdenie zmien vykonaných v databáze vo VCS
4. Opätovné spustenie vývojára refresh.sh, potom verifyDumpktorý teraz zobrazuje zoznam zmien, ktoré sa majú zahrnúť do migrácie
5. Vývojár prenesie celú zmenu štruktúry do migračného súboru a znova ho spustí refresh.sh и verifyDumpa ak je migrácia správne skompilovaná, verifyDump neukáže žiadne rozdiely medzi lokálnou databázou a uloženým výpisom

Vyššie opísaný proces je kompatibilný s princípmi gitflow. Každá vetva vo VCS bude obsahovať vlastnú verziu výpisu a pri zlučovaní vetiev budú výpisy zlúčené. Vo väčšine prípadov nie je potrebné po zlúčení vykonať žiadnu ďalšiu akciu, ale ak boli vykonané zmeny v rôznych vetvách, napríklad v tej istej tabuľke, môže dôjsť ku konfliktu.

Uvažujme o konfliktnej situácii na príklade: existuje pobočka rozvíjať, z ktorej sa vetvia dve pobočky: feature1 и feature2, ktoré nemajú konflikty s rozvíjať, ale majú medzi sebou konflikty. Úlohou je spojiť obe vetvy do rozvíjať. V tomto prípade sa odporúča najprv zlúčiť jednu z vetiev rozvíjaťa potom zlúčiť rozvíjať do zostávajúcej vetvy, vyriešením konfliktov v zostávajúcej vetve a následným zlúčením poslednej vetvy rozvíjať. Počas fázy riešenia konfliktov možno budete musieť opraviť migračný súbor v poslednej vetve tak, aby sa zhodoval s konečným výpisom, ktorý obsahuje výsledky zlúčení.

Ako bezpečne nasadiť viac zmien v štruktúre databázy do produkčného prostredia

Vďaka prítomnosti výpisu aktuálnej databázovej štruktúry vo VCS je možné kontrolovať produkčnú databázu na presnú zhodu s požadovanou štruktúrou. To zaisťuje, že všetky zmeny, ktoré vývojári zamýšľali, boli úspešne prenesené do produkčnej základne.

Ako DDL v PostgreSQL je transakčný, odporúča sa dodržať nasledovné poradie nasadenia, aby ste v prípade neočakávanej chyby mohli „bezbolestne“ spustiť ROLLBACK:

1. Začať transakciu
2. Vykonajte všetky migrácie v transakcii
3. V tej istej transakcii vykonajte deployDump
4. Bez dokončenia transakcie vykonajte verifyDump. Ak nie sú žiadne chyby, spustite COMMIT. Ak sa vyskytnú chyby, spustite ROLLBACK

Tieto kroky možno celkom jednoducho integrovať do existujúcich prístupov k nasadzovaniu aplikácií vrátane nulových prestojov.

Záver

Vďaka vyššie popísaným metódam je možné z projektov „PHP + PostgreSQL“ vyžmýkať maximálny výkon a zároveň obetovať relatívne malé pohodlie pri vývoji v porovnaní s implementáciou celej obchodnej logiky do hlavného aplikačného kódu. Okrem toho spracovanie údajov v PL/pgSQL často vyzerá transparentnejšie a vyžaduje menej kódu ako rovnaká funkcionalita napísaná v PHP.

Zdroj: hab.com