A cikk célja egy könyvtár példáján alapul séma-őrző olyan eszközöket mutat be, amelyek jelentősen leegyszerűsíthetik az adatbázisok fejlesztésének folyamatát PHP-projekteken belül a PostgreSQL DBMS használatával.

A cikkben található információk mindenekelőtt azoknak a fejlesztőknek lesznek hasznosak, akik szeretnék a legtöbbet kihozni a PostgreSQL képességeiből, de az adatbázisban elhelyezett üzleti logika fenntartásával kapcsolatos problémákkal szembesülnek.

Ez a cikk nem írja le az üzleti logika adatbázisban való tárolásának előnyeit vagy hátrányait. Feltételezzük, hogy a választást az olvasó már megtette.

A következő kérdéseket fogják mérlegelni:

1. Milyen formában kell egy adatbázis-struktúra kiíratót tárolni egy verziókezelő rendszerben (a továbbiakban: VCS)?
2. Hogyan lehet nyomon követni az adatbázis-struktúra változásait a kiíratás mentése után
3. Hogyan vihetjük át az adatbázis-struktúra változásait más környezetekbe ütközések és óriási migrációs fájlok nélkül
4. Hogyan lehet megszervezni a több fejlesztő párhuzamos munkájának folyamatát egy projekten
5. Hogyan lehet biztonságosan üzembe helyezni több változtatást az adatbázis-struktúrában éles környezetben
   

   SchemaKeeper a nyelven írt tárolt eljárásokkal való munkavégzéshez készült PL/pgSQL. Más nyelveken nem végeztek tesztelést, így előfordulhat, hogy a használat nem olyan hatékony, vagy nem lehetséges.

Hogyan tárolhatunk adatbázis-struktúra kiíratást a VCS-ben

könyvtár séma-őrző funkciót biztosít saveDump, amely az összes objektum szerkezetét külön szöveges fájlként menti az adatbázisból. A kimenet egy könyvtár, amely tartalmazza az adatbázis-struktúrát, csoportosított fájlokra osztva, amelyek könnyen hozzáadhatók a VCS-hez.

Nézzük meg, hogyan lehet objektumokat konvertálni adatbázisból fájlokká több példán keresztül:

Objektum típusa
A rendszer
Név
A fájl relatív elérési útja

táblázat
nyilvános
számlák
./public/tables/accounts.txt

Tárolt eljárás
nyilvános
auth (hash bigint)
./public/functions/auth(int8).sql

gondolat
foglalás
tarifák
./booking/views/tariffs.txt

A fájlok tartalma egy adott adatbázis-objektum szerkezetének szöveges megjelenítése. Például tárolt eljárások esetén a fájl tartalma a tárolt eljárás teljes definíciója lesz, a blokkkal kezdve CREATE OR REPLACE FUNCTION.

Amint a fenti táblázatból látható, a fájl elérési útja információkat tárol az objektum típusáról, sémájáról és nevéről. Ez a megközelítés megkönnyíti a navigálást az adatbázis változásainak kiíratása és kódvizsgálata között.

kiterjesztés .sql a tárolt eljárási forráskóddal rendelkező fájlok esetében ez úgy lett kiválasztva, hogy az IDE automatikusan eszközöket biztosítson az adatbázissal való interakcióhoz a fájl megnyitásakor.

Hogyan lehet nyomon követni az adatbázis-struktúra változásait a kiíratás mentése után

Az aktuális adatbázis-struktúra kiíratásának VCS-be mentésével lehetőséget kapunk annak ellenőrzésére, hogy a kiíratás létrehozása után történt-e változtatás az adatbázis-struktúrában. A könyvtárban séma-őrző Az adatbázis szerkezetében bekövetkezett változások észlelésére egy funkció biztosított verifyDump, amely mellékhatások nélkül ad vissza információkat a különbségekről.

Az ellenőrzés másik módja a függvény újbóli meghívása saveDump, ugyanazt a könyvtárat adja meg, és ellenőrizze a VCS-ben a változásokat. Mivel az adatbázisból minden objektum külön fájlba kerül, a VCS csak a megváltozott objektumokat mutatja.
Ennek a módszernek a fő hátránya, hogy felül kell írni a fájlokat a változások megtekintéséhez.

Hogyan vihetjük át az adatbázis-struktúra változásait más környezetekbe ütközések és óriási migrációs fájlok nélkül

A funkciónak köszönhetően deployDump A tárolt eljárások forráskódja pontosan ugyanúgy szerkeszthető, mint a hagyományos alkalmazás forráskódja. Hozzáadhat/törölhet új sorokat a tárolt eljáráskódban, és azonnal módosíthatja a verzióvezérlést, vagy létrehozhat/törölhet tárolt eljárásokat a megfelelő fájlok létrehozásával/törlésével a dump könyvtárban.

Például egy új tárolt eljárás létrehozásához egy sémában public csak hozzon létre egy új fájlt a kiterjesztéssel .sql a címtárban public/functions, helyezze el benne a tárolt eljárás forráskódját, beleértve a blokkot is CREATE OR REPLACE FUNCTION, majd hívja meg a függvényt deployDump. A tárolt eljárás módosítása és törlése ugyanúgy történik. Így a kód egyszerre kerül be a VCS-be és az adatbázisba.

Ha hiba jelenik meg bármely tárolt eljárás forráskódjában, vagy eltérés van a fájl és a tárolt eljárás neve között, akkor deployDump sikertelen lesz, hibaüzenet jelenik meg. Használat közben lehetetlen a tárolt eljárások eltérése a kiíratás és az aktuális adatbázis között deployDump.

Új tárolt eljárás létrehozásakor nincs szükség a megfelelő fájlnév manuális megadására. Elég, ha a fájl kiterjesztése van .sql. A hívás után deployDump a hibaszöveg a helyes nevet fogja tartalmazni, amivel át lehet nevezni a fájlt.

deployDump lehetővé teszi egy függvény vagy visszatérési típus paramétereinek módosítását további műveletek nélkül, míg a klasszikus megközelítéssel erre lenne szükség
először végrehajtani DROP FUNCTION, és csak akkor CREATE OR REPLACE FUNCTION.

Sajnos vannak olyan helyzetek, amikor deployDump nem tudja automatikusan alkalmazni a változtatásokat. Például, ha egy olyan trigger függvényt eltávolítanak, amelyet legalább egy trigger használ. Az ilyen helyzeteket a migrációs fájlok segítségével kézzel oldják meg.

Ha Ön felelős a tárolt eljárások módosításainak áttelepítéséért séma-őrző, akkor a migrációs fájlokat kell használni a szerkezet egyéb módosításainak átviteléhez. Például egy jó könyvtár az áttelepítésekkel való munkához doktrína/migrációk.

Az áttelepítéseket az indítás előtt kell alkalmazni deployDump. Ez lehetővé teszi a struktúra összes módosítását és a problémás helyzetek megoldását úgy, hogy a tárolt eljárások változásait később problémamentesen átvigye.

Az áttelepítésekkel végzett munka részletesebb leírása a következő szakaszokban lesz.

Hogyan lehet megszervezni a több fejlesztő párhuzamos munkájának folyamatát egy projekten

Létre kell hozni egy szkriptet az adatbázis teljes inicializálásához, amelyet a fejlesztő elindít a munkagépén, összhangba hozva a helyi adatbázis felépítését a VCS-ben elmentett kiíratással. A legegyszerűbb módja, ha a helyi adatbázis inicializálását három lépésre osztja:

1. Importáljunk egy alapstruktúrájú fájlt, aminek a neve pl. base.sql
2. Migrációk alkalmazása
3. hívás deployDump

base.sql az a kiindulópont, amelyen felül a migráció kerül alkalmazásra és végrehajtásra deployDumpEz azt jelenti, base.sql + миграции + deployDump = актуальная структура БД. A segédprogram segítségével létrehozhat ilyen fájlt pg_dump. Használt base.sql kizárólag az adatbázis nulláról történő inicializálásakor.

Az adatbázis teljes inicializálásához hívjuk meg a szkriptet refresh.sh. A munkafolyamat így nézhet ki:

1. A fejlesztő a környezetében indul refresh.sh és megkapja az aktuális adatbázis-struktúrát
2. A fejlesztő megkezdi a munkát az adott feladaton, módosítva a helyi adatbázist, hogy megfeleljen az új funkció igényeinek (ALTER TABLE ... ADD COLUMN stb)
3. A feladat elvégzése után a fejlesztő meghívja a függvényt saveDumpaz adatbázisban végrehajtott változtatások végrehajtásához a VCS-ben
4. Fejlesztői újraindítás refresh.sh, akkor verifyDumpamely most az áttelepítésbe bevonandó változtatások listáját mutatja
5. A fejlesztő az összes szerkezeti változást átviszi a migrációs fájlba, és újra lefut refresh.sh и verifyDump, és ha az áttelepítés helyesen lett összeállítva, verifyDump nem mutat különbséget a helyi adatbázis és a mentett dump között

A fent leírt folyamat kompatibilis a gitflow elveivel. A VCS-ben minden ág tartalmazni fogja a kiíratás saját verzióját, és az ágak egyesítésekor a dumpok összevonódnak. Az esetek többségében az összevonást követően nincs szükség további teendőkre, de ha különböző ágakban, például ugyanabban a táblában változtatásokat hajtanak végre, ütközés léphet fel.

Tekintsünk egy konfliktushelyzetet egy példán keresztül: van egy elágazás Fejleszt, amelyből két ág ágazik: feature1 и feature2, amelyekkel nincs konfliktus Fejleszt, de konfliktusai vannak egymással. A feladat mindkét ág összevonása Fejleszt. Ebben az esetben ajánlatos először az egyik ágat egyesíteni Fejlesztmajd egyesítik Fejleszt a fennmaradó ágra, a fennmaradó ágban feloldva a konfliktusokat, majd az utolsó ágat beolvasztani Fejleszt. A konfliktusfeloldási szakaszban előfordulhat, hogy javítania kell az utolsó ágban lévő áttelepítési fájlt, hogy megfeleljen a végső kiíratnak, amely tartalmazza az összevonások eredményeit.

Hogyan lehet biztonságosan üzembe helyezni több változtatást az adatbázis-struktúrában éles környezetben

A jelenlegi adatbázis-struktúra kiíratásának köszönhetően a VCS-ben lehetővé válik annak ellenőrzése, hogy a termelési adatbázis pontosan megfelel-e a szükséges struktúrának. Ez biztosítja, hogy a fejlesztők által tervezett összes változtatás sikeresen átkerüljön a gyártóbázisba.

Mint DDL a PostgreSQL-ben az tranzakciós, javasoljuk az alábbi telepítési sorrend betartását, hogy váratlan hiba esetén „fájdalommentesen” lehessen végrehajtani ROLLBACK:

1. Tranzakció indítása
2. Végezze el az összes migrációt egy tranzakcióban
3. Ugyanabban a tranzakcióban hajtsa végre deployDump
4. A tranzakció befejezése nélkül hajtsa végre verifyDump. Ha nincs hiba, futtassa COMMIT. Ha hibák vannak, futtassa ROLLBACK

Ezek a lépések könnyen integrálhatók az alkalmazástelepítés meglévő megközelítéseibe, beleértve a nulla állásidőt is.

Következtetés

A fent leírt módszereknek köszönhetően a „PHP + PostgreSQL” projektekből maximális teljesítményt lehet kicsikarni, miközben viszonylag kevés fejlesztési kényelmet kell feláldozni ahhoz képest, hogy az összes üzleti logikát a fő alkalmazáskódban implementálják. Sőt, az adatfeldolgozás be PL/pgSQL gyakran átláthatóbbnak tűnik, és kevesebb kódot igényel, mint ugyanaz a funkcionalitás, amely PHP-ben íródott.

Forrás: will.com