Účelem tohoto článku je použít příklad knihovny správce schématu ukázat nástroje, které mohou výrazně zjednodušit proces vývoje databází v rámci projektů PHP pomocí PostgreSQL DBMS.

Informace z tohoto článku budou v první řadě užitečné pro vývojáře, kteří chtějí maximálně využít schopnosti PostgreSQL, ale potýkají se s problémy s udržováním obchodní logiky umístěné v databázi.

Tento článek nebude popisovat výhody nebo nevýhody ukládání obchodní logiky do databáze. Předpokládá se, že výběr již provedl čtenář.

Budou zváženy následující otázky:

1. V jaké formě by měl být uložen výpis struktury databáze v systému správy verzí (dále jen VCS)
2. Jak sledovat změny ve struktuře databáze po uložení výpisu
3. Jak přenést změny ve struktuře databáze do jiných prostředí bez konfliktů a obřích migračních souborů
4. Jak zorganizovat proces paralelní práce na projektu několika vývojářů
5. Jak bezpečně nasadit více změn ve struktuře databáze do produkčního prostředí
   

   SchemaKeeper navržený pro práci s uloženými procedurami napsanými v jazyce PL/pgSQL. Testování s jinými jazyky nebylo provedeno, takže použití nemusí být tak efektivní nebo nemusí být možné.

Jak uložit výpis struktury databáze ve VCS

knihovna správce schématu poskytuje funkci saveDump, který ukládá strukturu všech objektů z databáze jako samostatné textové soubory. Výstupem je adresář obsahující strukturu databáze, rozdělený do seskupených souborů, které lze snadno přidat do VCS.

Podívejme se na převod objektů z databáze na soubory na několika příkladech:

Typ objektu
systém
Jméno
Relativní cesta k souboru

stůl
na veřejnosti
účty
./public/tables/accounts.txt

Uložené procedury
na veřejnosti
auth (hash bigint)
./public/functions/auth(int8).sql

Úvod
Rezervace
tarify
./booking/views/tariffs.txt

Obsah souborů je textovou reprezentací struktury konkrétního databázového objektu. Například pro uložené procedury bude obsahem souboru úplná definice uložené procedury počínaje blokem CREATE OR REPLACE FUNCTION.

Jak je vidět z tabulky výše, cesta k souboru uchovává informace o typu, schématu a názvu objektu. Tento přístup usnadňuje procházení výpisem a kontrolou kódu změn v databázi.

prodloužení .sql pro soubory se zdrojovým kódem uložené procedury to bylo vybráno tak, aby IDE automaticky poskytovalo nástroje pro interakci s databází při otevření souboru.

Jak sledovat změny ve struktuře databáze po uložení výpisu

Uložením výpisu aktuální struktury databáze ve VCS získáme možnost zkontrolovat, zda po vytvoření výpisu nebyly provedeny změny ve struktuře databáze. V knihovně správce schématu pro detekci změn ve struktuře databáze je k dispozici funkce verifyDump, který vrací informace o rozdílech bez vedlejších účinků.

Alternativní způsob kontroly je zavolat funkci znovu saveDump, zadejte stejný adresář a zkontrolujte změny ve VCS. Protože všechny objekty z databáze jsou uloženy v samostatných souborech, VCS zobrazí pouze změněné objekty.
Hlavní nevýhodou této metody je nutnost přepisování souborů, aby bylo možné vidět změny.

Jak přenést změny ve struktuře databáze do jiných prostředí bez konfliktů a obřích migračních souborů

Díky funkci deployDump Zdrojový kód uložených procedur lze upravovat přesně stejným způsobem jako zdrojový kód běžné aplikace. Můžete přidávat/odstraňovat nové řádky v kódu uložené procedury a okamžitě zasílat změny do správy verzí, nebo vytvářet/odstraňovat uložené procedury vytvořením/smazáním odpovídajících souborů v adresáři výpisu.

Chcete-li například vytvořit novou uloženou proceduru ve schématu public stačí vytvořit nový soubor s příponou .sql v adresáři public/functions, umístěte do něj zdrojový kód uložené procedury včetně bloku CREATE OR REPLACE FUNCTIONa poté funkci zavolejte deployDump. Úprava a odstranění uložené procedury probíhá stejným způsobem. Kód tedy jde do VCS i do databáze současně.

Pokud se ve zdrojovém kódu jakékoli uložené procedury objeví chyba nebo nesrovnalosti mezi názvy souboru a uložené procedury, pak deployDump selže a zobrazí se chybový text. Nesoulad uložených procedur mezi výpisem a aktuální databází je při použití nemožný deployDump.

Při vytváření nové uložené procedury není nutné ručně zadávat správný název souboru. Stačí, aby měl soubor příponu .sql. Po hovoru deployDump chybový text bude obsahovat správný název, který lze použít k přejmenování souboru.

deployDump umožňuje změnit parametry funkce nebo návratového typu bez dalších akcí, zatímco u klasického přístupu byste to museli udělat
provést první DROP FUNCTION, a teprve potom CREATE OR REPLACE FUNCTION.

Bohužel existují situace, kdy deployDump nelze automaticky aplikovat změny. Například pokud je odstraněna spouštěcí funkce, kterou používá alespoň jeden spouštěč. Takové situace se řeší ručně pomocí migračních souborů.

Pokud jste odpovědní za migraci změn do uložených procedur správce schématu, pak je nutné použít migrační soubory k přenosu dalších změn ve struktuře. Dobrá knihovna pro práci s migracemi je například doktrína/migrace.

Migrace musí být aplikovány před spuštěním deployDump. To umožňuje provádět veškeré změny struktury a řešit problematické situace tak, aby se změny v uložených procedurách následně bez problémů přenesly.

Práce s migracemi bude podrobněji popsána v následujících částech.

Jak zorganizovat proces paralelní práce na projektu několika vývojářů

Pro kompletní inicializaci databáze je nutné vytvořit skript, který spustí vývojář na svém pracovním stroji, čímž uvede strukturu lokální databáze do souladu s výpisem uloženým ve VCS. Nejjednodušší způsob je rozdělit inicializaci lokální databáze do 3 kroků:

1. Importujte soubor se základní strukturou, která se bude jmenovat např. base.sql
2. Aplikace migrací
3. Výzva deployDump

base.sql je výchozím bodem, nad kterým se migrace aplikují a spouštějí deployDumpTo znamená, že base.sql + миграции + deployDump = актуальная структура БД. Takový soubor můžete vytvořit pomocí nástroje pg_dump. Použitý base.sql výhradně při inicializaci databáze od začátku.

Zavolejte skript pro kompletní inicializaci databáze refresh.sh. Pracovní postup může vypadat takto:

1. Vývojář se spustí ve svém prostředí refresh.sh a získá aktuální strukturu databáze
2. Vývojář zahájí práci na daném úkolu a upraví místní databázi tak, aby vyhovovala potřebám nové funkce (ALTER TABLE ... ADD COLUMN atd)
3. Po dokončení úkolu zavolá vývojář funkci saveDumppro potvrzení změn provedených v databázi ve VCS
4. Opětovné spuštění vývojáře refresh.sh, pak verifyDumpkterý nyní zobrazuje seznam změn, které mají být zahrnuty do migrace
5. Vývojář přenese všechny změny struktury do migračního souboru a spustí se znovu refresh.sh и verifyDumpa pokud je migrace zkompilována správně, verifyDump neukáže žádné rozdíly mezi lokální databází a uloženým výpisem

Výše popsaný proces je kompatibilní s principy gitflow. Každá větev ve VCS bude obsahovat vlastní verzi výpisu a při slučování větví se výpisy sloučí. Ve většině případů není třeba po sloučení provádět žádnou další akci, ale pokud byly provedeny změny v různých větvích, například ve stejné tabulce, může dojít ke konfliktu.

Uvažujme konfliktní situaci na příkladu: existuje větev Rozvíjet, ze kterého se větví dvě větve: feature1 и feature2, které nemají žádné konflikty Rozvíjet, ale mají mezi sebou konflikty. Úkolem je sloučit obě větve do Rozvíjet. Pro tento případ se doporučuje nejprve sloučit jednu z větví do Rozvíjeta pak sloučit Rozvíjet do zbývající větve, vyřešení konfliktů ve zbývající větvi a následné sloučení poslední větve do Rozvíjet. Během fáze řešení konfliktů možná budete muset opravit migrační soubor v poslední větvi tak, aby odpovídal konečnému výpisu, který obsahuje výsledky sloučení.

Jak bezpečně nasadit více změn ve struktuře databáze do produkčního prostředí

Díky přítomnosti výpisu aktuální struktury databáze ve VCS je možné zkontrolovat produkční databázi, zda přesně odpovídá požadované struktuře. Tím je zajištěno, že všechny změny, které vývojáři zamýšleli, byly úspěšně přeneseny do produkční základny.

Jak DDL v PostgreSQL je transakční, je doporučeno dodržet následující pořadí nasazení, abyste v případě neočekávané chyby mohli „bezbolestně“ spustit ROLLBACK:

1. Zahájit transakci
2. Proveďte všechny migrace v transakci
3. Ve stejné transakci proveďte deployDump
4. Bez dokončení transakce proveďte verifyDump. Pokud nejsou žádné chyby, spusťte COMMIT. Pokud jsou chyby, spusťte ROLLBACK

Tyto kroky lze snadno integrovat do stávajících přístupů k nasazení aplikací, včetně nulových prostojů.

Závěr

Díky výše popsaným metodám je možné z projektů „PHP + PostgreSQL“ vymáčknout maximální výkon a přitom obětovat relativně malé pohodlí při vývoji ve srovnání s implementací veškeré obchodní logiky v kódu hlavní aplikace. Navíc zpracování dat v PL/pgSQL často vypadá transparentněji a vyžaduje méně kódu než stejná funkce napsaná v PHP.

Zdroj: www.habr.com