Syftet med den här artikeln är att använda exemplet med ett bibliotek schemahållare visa verktyg som avsevärt kan förenkla processen att utveckla databaser inom PHP-projekt med hjälp av PostgreSQL DBMS.

Informationen från den här artikeln kommer först och främst att vara användbar för utvecklare som vill få ut det mesta av PostgreSQL-kapaciteten, men som står inför problem med att upprätthålla affärslogik placerad i databasen.

Den här artikeln kommer inte att beskriva fördelarna eller nackdelarna med att lagra affärslogik i en databas. Det antas att valet redan har gjorts av läsaren.

Följande frågor kommer att behandlas:

1. I vilken form ska en databasstrukturdump lagras i ett versionskontrollsystem (nedan kallat VCS)
2. Hur man spårar ändringar i databasstrukturen efter att ha sparat en dump
3. Hur man överför ändringar i databasstrukturen till andra miljöer utan konflikter och gigantiska migreringsfiler
4. Hur man organiserar processen för parallellt arbete med ett projekt av flera utvecklare
5. Hur man säkert distribuerar fler ändringar i databasstrukturen till en produktionsmiljö
   

   SchemaKeeper designad för att arbeta med lagrade procedurer skrivna på språket PL/pgSQL. Testning med andra språk har inte utförts, så användningen kanske inte är lika effektiv eller inte är möjlig.

Hur man lagrar en databasstrukturdump i VCS

Bibliotek schemahållare ger en funktion saveDump, som sparar strukturen för alla objekt från databasen som separata textfiler. Utdata är en katalog som innehåller databasstrukturen, uppdelad i grupperade filer som enkelt kan läggas till i VCS.

Låt oss titta på att konvertera objekt från en databas till filer med hjälp av flera exempel:

Objekttyp
Schemat
namn
Relativ sökväg till fil

bord
allmän
konton
./public/tables/accounts.txt

Lagrad procedur
allmän
auth (hash bigint)
./public/functions/auth(int8).sql

idé
bokning
tariffer
./booking/views/tariffs.txt

Innehållet i filerna är en textmässig representation av strukturen för ett specifikt databasobjekt. Till exempel, för lagrade procedurer, kommer innehållet i filen att vara den fullständiga definitionen av den lagrade proceduren, med början med blocket CREATE OR REPLACE FUNCTION.

Som framgår av tabellen ovan lagrar sökvägen till filen information om objektets typ, schema och namn. Detta tillvägagångssätt gör det lättare att navigera genom dumpningen och kodgranskningen av ändringar i databasen.

förlängning .sql för filer med lagrad procedurkällkod valdes detta så att IDE automatiskt tillhandahåller verktyg för att interagera med databasen när filen öppnas.

Hur man spårar ändringar i databasstrukturen efter att ha sparat en dump

Genom att spara en dump av den aktuella databasstrukturen i VCS får vi möjlighet att kontrollera om ändringar gjorts i databasstrukturen efter att dumpen skapats. På biblioteket schemahållare för att upptäcka förändringar i databasstrukturen tillhandahålls en funktion verifyDump, som returnerar information om skillnaderna utan biverkningar.

Ett alternativt sätt att kontrollera är att anropa funktionen igen saveDump, ange samma katalog och kontrollera i VCS för ändringar. Eftersom alla objekt från databasen är sparade i separata filer kommer VCS endast att visa ändrade objekt.
Den största nackdelen med denna metod är behovet av att skriva över filer för att se ändringarna.

Hur man överför ändringar i databasstrukturen till andra miljöer utan konflikter och gigantiska migreringsfiler

Tack vare funktionen deployDump Källkoden för lagrade procedurer kan redigeras på exakt samma sätt som den vanliga applikationens källkod. Du kan lägga till/ta bort nya rader i lagrad procedurkod och omedelbart pusha ändringar till versionskontroll, eller skapa/ta bort lagrade procedurer genom att skapa/ta bort motsvarande filer i dumpkatalogen.

Till exempel för att skapa en ny lagrad procedur i ett schema public skapa bara en ny fil med tillägget .sql i katalogen public/functions, placera källkoden för den lagrade proceduren i den, inklusive blocket CREATE OR REPLACE FUNCTION, anropa sedan funktionen deployDump. Ändring och borttagning av en lagrad procedur sker på samma sätt. Således går koden in i både VCS och databasen samtidigt.

Om ett fel visas i källkoden för någon lagrad procedur, eller en avvikelse mellan namnen på filen och den lagrade proceduren, deployDump kommer att misslyckas, visar feltext. Felöverensstämmelse mellan lagrade procedurer mellan dumpen och den aktuella databasen är omöjlig vid användning deployDump.

När du skapar en ny lagrad procedur behöver du inte ange korrekt filnamn manuellt. Det räcker att filen har filtillägget .sql. Efter samtalet deployDump feltexten kommer att innehålla det korrekta namnet, som kan användas för att byta namn på filen.

deployDump låter dig ändra parametrarna för en funktion eller returtyp utan ytterligare åtgärder, medan du med den klassiska metoden måste
exekvera först DROP FUNCTION, och först då CREATE OR REPLACE FUNCTION.

Tyvärr finns det vissa situationer där deployDump kan inte tillämpa ändringar automatiskt. Till exempel om en triggerfunktion som används av minst en trigger tas bort. Sådana situationer löses manuellt med hjälp av migreringsfiler.

Om du är ansvarig för att migrera ändringar av lagrade procedurer schemahållare, då måste migreringsfiler användas för att överföra andra ändringar i strukturen. Ett bra bibliotek för att arbeta med migrationer är till exempel doktrin/migrationer.

Migrering måste tillämpas före lansering deployDump. Detta gör att du kan göra alla ändringar i strukturen och lösa problematiska situationer så att ändringar i lagrade procedurer därefter överförs utan problem.

Arbetet med migrering kommer att beskrivas mer i detalj i följande avsnitt.

Hur man organiserar processen för parallellt arbete med ett projekt av flera utvecklare

Det är nödvändigt att skapa ett skript för fullständig initialisering av databasen, som kommer att lanseras av utvecklaren på sin arbetsmaskin, vilket gör att strukturen för den lokala databasen överensstämmer med dumpen som sparats i VCS. Det enklaste sättet är att dela upp initieringen av den lokala databasen i 3 steg:

1. Importera en fil med en grundstruktur som kommer att heta t.ex. base.sql
2. Tillämpa migrationer
3. samtal deployDump

base.sql är utgångspunkten ovanpå vilken migrering tillämpas och exekveras deployDumpDet är, base.sql + миграции + deployDump = актуальная структура БД. Du kan skapa en sådan fil med hjälp av verktyget pg_dump. Begagnade base.sql endast vid initialisering av databasen från början.

Låt oss kalla skriptet för fullständig databasinitiering refresh.sh. Arbetsflödet kan se ut så här:

1. Utvecklaren lanserar i sin miljö refresh.sh och får den aktuella databasstrukturen
2. Utvecklaren börjar arbeta med uppgiften och modifierar den lokala databasen för att möta behoven hos den nya funktionaliteten (ALTER TABLE ... ADD COLUMN etc)
3. Efter att ha slutfört uppgiften anropar utvecklaren funktionen saveDumpatt utföra ändringar som gjorts i databasen i VCS
4. Relansering av utvecklare refresh.shdå verifyDumpsom nu visar en lista över ändringar som ska inkluderas i migreringen
5. Utvecklaren överför alla strukturändringar till migreringsfilen, körs igen refresh.sh и verifyDumpoch, om migreringen är korrekt kompilerad, verifyDump visar inga skillnader mellan den lokala databasen och den sparade dumpen

Processen som beskrivs ovan är kompatibel med gitflow-principerna. Varje gren i VCS kommer att innehålla sin egen version av dumpen, och när grenar slås samman kommer dumparna att slås samman. I de flesta fall behöver inga ytterligare åtgärder vidtas efter en sammanslagning, men om ändringar gjordes i olika grenar, till exempel i samma tabell, kan en konflikt uppstå.

Låt oss överväga en konfliktsituation med ett exempel: det finns en gren utveckla, varifrån två grenar förgrenar sig: feature1 и feature2, som inte har några konflikter med utveckla, men har konflikter med varandra. Uppgiften är att slå samman båda grenarna till utveckla. I det här fallet rekommenderas det att först slå samman en av grenarna till utvecklaoch slå samman utveckla till den återstående grenen, lösa konflikter i den återstående grenen och sedan slå samman den sista grenen till utveckla. Under konfliktlösningsfasen kan du behöva fixa migreringsfilen i den sista grenen så att den matchar den slutliga dumpningen, som inkluderar resultaten av sammanslagningarna.

Hur man säkert distribuerar fler ändringar i databasstrukturen till en produktionsmiljö

Tack vare närvaron av en dump av den nuvarande databasstrukturen i VCS blir det möjligt att kontrollera produktionsdatabasen för exakt överensstämmelse med den nödvändiga strukturen. Detta säkerställer att alla ändringar som utvecklarna avsåg framgångsrikt överfördes till produktionsbasen.

Som DDL i PostgreSQL är transaktionella, rekommenderas att följa följande distributionsordning, så att du, i händelse av ett oväntat fel, kan "smärtfritt" utföra ROLLBACK:

1. Starta transaktionen
2. Utför alla migreringar i en transaktion
3. I samma transaktion, exekvera deployDump
4. Utför utan att slutföra transaktionen verifyDump. Om det inte finns några fel, kör COMMIT. Om det finns fel, kör ROLLBACK

Dessa steg kan enkelt integreras i befintliga metoder för implementering av applikationer, inklusive noll driftstopp.

Slutsats

Tack vare metoderna som beskrivs ovan är det möjligt att pressa ut maximal prestanda ur "PHP + PostgreSQL"-projekt, samtidigt som man offra relativt lite utvecklingsbekvämlighet jämfört med att implementera all affärslogik i huvudapplikationskoden. Dessutom databehandling i PL/pgSQL ser ofta mer transparent ut och kräver mindre kod än samma funktionalitet skriven i PHP.

Källa: will.com