Formålet med denne artikel er at bruge eksemplet på et bibliotek skema-holder vise værktøjer, der væsentligt kan forenkle processen med at udvikle databaser inden for PHP-projekter ved hjælp af PostgreSQL DBMS.

Oplysningerne fra denne artikel vil først og fremmest være nyttige for udviklere, der ønsker at få mest muligt ud af PostgreSQL-kapaciteter, men som står over for problemer med at opretholde forretningslogik placeret i databasen.

Denne artikel vil ikke beskrive fordele eller ulemper ved at gemme forretningslogik i en database. Det antages, at valget allerede er truffet af læseren.

Følgende spørgsmål vil blive overvejet:

1. I hvilken form skal en databasestrukturdump lagres i et versionskontrolsystem (i det følgende benævnt VCS)
2. Sådan spores ændringer i databasestrukturen efter at have gemt et dump
3. Sådan overfører du ændringer i databasestrukturen til andre miljøer uden konflikter og gigantiske migrationsfiler
4. Hvordan man organiserer processen med parallelt arbejde på et projekt af flere udviklere
5. Sådan implementerer du sikkert flere ændringer i databasestrukturen til et produktionsmiljø
   

   SchemaKeeper designet til at arbejde med lagrede procedurer skrevet på sproget PL/pgSQL. Test med andre sprog er ikke blevet udført, så brugen er muligvis ikke så effektiv eller er muligvis ikke mulig.

Sådan gemmer du et databasestrukturdump i VCS

bibliotek skema-holder giver en funktion saveDump, som gemmer strukturen af ​​alle objekter fra databasen som separate tekstfiler. Outputtet er en mappe, der indeholder databasestrukturen, opdelt i grupperede filer, der nemt kan tilføjes til VCS.

Lad os se på at konvertere objekter fra en database til filer ved hjælp af flere eksempler:

Objekttype
Ordningen
Navn
Relativ sti til fil

bord
offentlige
konti
./public/tables/accounts.txt

Lagret procedure
offentlige
auth (hash bigint)
./public/functions/auth(int8).sql

idé
booking
takster
./booking/views/tariffs.txt

Indholdet af filerne er en tekstlig repræsentation af strukturen af ​​et specifikt databaseobjekt. For eksempel, for lagrede procedurer, vil indholdet af filen være den fulde definition af den lagrede procedure, startende med blokken CREATE OR REPLACE FUNCTION.

Som det kan ses af tabellen ovenfor, gemmer stien til filen information om objektets type, skema og navn. Denne tilgang gør det nemmere at navigere gennem dumpet og kodegennemgangen af ​​ændringer i databasen.

udvidelse .sql for filer med lagret procedure kildekode er dette valgt, så IDE automatisk giver værktøjer til at interagere med databasen, når filen åbnes.

Sådan spores ændringer i databasestrukturen efter at have gemt et dump

Ved at gemme et dump af den aktuelle databasestruktur i VCS, får vi mulighed for at tjekke om der er lavet ændringer i databasestrukturen efter dumpet blev oprettet. På biblioteket skema-holder for at opdage ændringer i databasestrukturen er der tilvejebragt en funktion verifyDump, som returnerer information om forskellene uden bivirkninger.

En alternativ måde at kontrollere er at kalde funktionen igen saveDump, angiv den samme mappe, og tjek i VCS for ændringer. Da alle objekter fra databasen er gemt i separate filer, vil VCS kun vise ændrede objekter.
Den største ulempe ved denne metode er behovet for at overskrive filer for at se ændringerne.

Sådan overfører du ændringer i databasestrukturen til andre miljøer uden konflikter og gigantiske migrationsfiler

Takket være funktionen deployDump Kildekoden for lagrede procedurer kan redigeres på nøjagtig samme måde som den almindelige applikationskildekode. Du kan tilføje/slette nye linjer i lagret procedurekode og straks skubbe ændringer til versionskontrol, eller oprette/slette lagrede procedurer ved at oprette/slette de tilsvarende filer i dumpmappen.

For eksempel at oprette en ny lagret procedure i et skema public bare opret en ny fil med filtypenavnet .sql i mappen public/functions, placer kildekoden for den lagrede procedure i den, inklusive blokken CREATE OR REPLACE FUNCTION, kald derefter funktionen deployDump. Ændring og sletning af en lagret procedure foregår på samme måde. Således går koden ind i både VCS og databasen på samme tid.

Hvis der vises en fejl i kildekoden for en lagret procedure, eller en uoverensstemmelse mellem navnene på filen og den lagrede procedure, deployDump mislykkes, viser fejltekst. Uoverensstemmelse mellem lagrede procedurer mellem dumpet og den aktuelle database er umuligt ved brug deployDump.

Når du opretter en ny lagret procedure, er det ikke nødvendigt at indtaste det korrekte filnavn manuelt. Det er nok for filen at have filtypenavnet .sql. Efter opkaldet deployDump fejlteksten vil indeholde det korrekte navn, som kan bruges til at omdøbe filen.

deployDump giver dig mulighed for at ændre parametrene for en funktion eller returtype uden yderligere handlinger, mens du med den klassiske tilgang skal
udføre først DROP FUNCTION, og først derefter CREATE OR REPLACE FUNCTION.

Desværre er der nogle situationer, hvor deployDump ude af stand til automatisk at anvende ændringer. For eksempel, hvis en triggerfunktion, der bruges af mindst én trigger, fjernes. Sådanne situationer løses manuelt ved hjælp af migreringsfiler.

Hvis du er ansvarlig for at migrere ændringer til lagrede procedurer skema-holder, så skal migreringsfiler bruges til at overføre andre ændringer i strukturen. For eksempel er et godt bibliotek til at arbejde med migreringer doktrin/migrationer.

Migreringer skal anvendes før lancering deployDump. Dette giver dig mulighed for at foretage alle ændringer i strukturen og løse problematiske situationer, så ændringer i lagrede procedurer efterfølgende overføres uden problemer.

Arbejdet med migreringer vil blive beskrevet mere detaljeret i de følgende afsnit.

Hvordan man organiserer processen med parallelt arbejde på et projekt af flere udviklere

Det er nødvendigt at oprette et script til fuldstændig initialisering af databasen, som vil blive lanceret af udvikleren på hans arbejdsmaskine, hvilket bringer strukturen af ​​den lokale database i overensstemmelse med dumpet, der er gemt i VCS. Den nemmeste måde er at opdele initialiseringen af ​​den lokale database i 3 trin:

1. Importer en fil med en grundstruktur, der vil hedde f.eks. base.sql
2. Anvendelse af migrationer
3. opkald deployDump

base.sql er udgangspunktet, hvorpå migreringer anvendes og udføres deployDumpDet vil sige, base.sql + миграции + deployDump = актуальная структура БД. Du kan oprette en sådan fil ved hjælp af hjælpeprogrammet pg_dump. Brugt base.sql udelukkende ved initialisering af databasen fra bunden.

Lad os kalde scriptet for fuldstændig databaseinitialisering refresh.sh. Arbejdsgangen kan se sådan ud:

1. Udvikleren lancerer i sit miljø refresh.sh og får den aktuelle databasestruktur
2. Udvikleren begynder at arbejde på opgaven ved at ændre den lokale database for at imødekomme behovene for den nye funktionalitet (ALTER TABLE ... ADD COLUMN etc)
3. Efter at have fuldført opgaven, kalder udvikleren funktionen saveDumpat begå ændringer i databasen i VCS
4. Relancering af udviklere refresh.sh, så verifyDumpsom nu viser en liste over ændringer, der skal inkluderes i migreringen
5. Udvikleren overfører alle strukturændringer til migrationsfilen, kører igen refresh.sh и verifyDump, og hvis migreringen er kompileret korrekt, verifyDump vil ikke vise nogen forskelle mellem den lokale database og det gemte dump

Processen beskrevet ovenfor er kompatibel med gitflow-principper. Hver filial i VCS'en vil indeholde sin egen version af dumpet, og ved sammenlægning af filialer vil dumpene blive flettet. I de fleste tilfælde skal der ikke foretages yderligere efter en fletning, men hvis der blev foretaget ændringer i forskellige afdelinger, for eksempel til den samme tabel, kan der opstå en konflikt.

Lad os overveje en konfliktsituation ved at bruge et eksempel: der er en gren udvikle, hvorfra to grene forgrener sig: feature1 и feature2, som ikke har nogen konflikter med udvikle, men har konflikter med hinanden. Opgaven er at slå begge grene sammen til udvikle. I dette tilfælde anbefales det først at flette en af ​​grenene ind i udvikleog derefter flette udvikle til den resterende gren, løse konflikter i den resterende gren og derefter flette den sidste gren ind i udvikle. Under konfliktløsningsfasen skal du muligvis rette migrationsfilen i den sidste gren, så den matcher det endelige dump, som inkluderer resultaterne af fletningerne.

Sådan implementerer du sikkert flere ændringer i databasestrukturen til et produktionsmiljø

Takket være tilstedeværelsen af ​​et dump af den nuværende databasestruktur i VCS, bliver det muligt at kontrollere produktionsdatabasen for nøjagtig overensstemmelse med den påkrævede struktur. Dette sikrer, at alle de ændringer, som udviklerne havde til hensigt, blev overført til produktionsbasen.

siden DDL i PostgreSQL er transaktionelle, anbefales det at overholde følgende implementeringsrækkefølge, så du i tilfælde af en uventet fejl kan "smertefrit" udføre ROLLBACK:

1. Start transaktion
2. Udfør alle migreringer i en transaktion
3. Udfør i samme transaktion deployDump
4. Udfør transaktionen uden at fuldføre verifyDump. Hvis der ikke er nogen fejl, så kør COMMIT. Hvis der er fejl, så kør ROLLBACK

Disse trin kan nemt integreres i eksisterende tilgange til applikationsimplementering, inklusive nul nedetid.

Konklusion

Takket være de ovenfor beskrevne metoder er det muligt at presse maksimal ydeevne ud af "PHP + PostgreSQL"-projekter, samtidig med at man ofrer relativt lidt udviklingskomfort sammenlignet med implementering af al forretningslogikken i hovedapplikationskoden. Desuden databehandling i PL/pgSQL ser ofte mere gennemsigtigt ud og kræver mindre kode end den samme funktionalitet skrevet i PHP.

Kilde: www.habr.com