Hensikten med denne artikkelen er å bruke eksemplet på et bibliotek skjemaholder vise verktøy som betydelig kan forenkle prosessen med å utvikle databaser i PHP-prosjekter ved å bruke PostgreSQL DBMS.

Informasjonen fra denne artikkelen vil for det første være nyttig for utviklere som ønsker å få mest mulig ut av PostgreSQL-funksjonene, men som står overfor problemer med å opprettholde forretningslogikk plassert i databasen.

Denne artikkelen vil ikke beskrive fordelene eller ulempene ved å lagre forretningslogikk i en database. Det forutsettes at valget allerede er tatt av leseren.

Følgende spørsmål vil bli vurdert:

1. I hvilken form skal en databasestrukturdump lagres i et versjonskontrollsystem (heretter kalt VCS)
2. Hvordan spore endringer i databasestrukturen etter å ha lagret en dump
3. Hvordan overføre endringer i databasestrukturen til andre miljøer uten konflikter og gigantiske migrasjonsfiler
4. Hvordan organisere prosessen med parallellarbeid på et prosjekt av flere utviklere
5. Hvordan trygt distribuere flere endringer i databasestrukturen til et produksjonsmiljø
   

   SchemaKeeper designet for å arbeide med lagrede prosedyrer skrevet på språket PL/pgSQL. Testing med andre språk har ikke blitt utført, så bruk er kanskje ikke like effektiv eller ikke mulig.

Hvordan lagre en databasestrukturdump i VCS

Bibliotek skjemaholder gir en funksjon saveDump, som lagrer strukturen til alle objekter fra databasen som separate tekstfiler. Utdataene er en katalog som inneholder databasestrukturen, delt inn i grupperte filer som enkelt kan legges til VCS.

La oss se på å konvertere objekter fra en database til filer ved å bruke flere eksempler:

Objekttype
Ordningen
Navn
Relativ bane til fil

bord
offentlig
kontoer
./public/tables/accounts.txt

Lagret prosedyre
offentlig
auth(hash bigint)
./public/functions/auth(int8).sql

Представление
bestilling
tariffer
./booking/views/tariffs.txt

Innholdet i filene er en tekstlig representasjon av strukturen til et spesifikt databaseobjekt. For eksempel, for lagrede prosedyrer, vil innholdet i filen være den fullstendige definisjonen av den lagrede prosedyren, og starter med blokken CREATE OR REPLACE FUNCTION.

Som det fremgår av tabellen ovenfor, lagrer banen til filen informasjon om type, skjema og navn på objektet. Denne tilnærmingen gjør det lettere å navigere gjennom dumpen og kodegjennomgangen av endringer i databasen.

forlengelse .sql for filer med lagret prosedyrekildekode ble dette valgt slik at IDE automatisk gir verktøy for å samhandle med databasen når filen åpnes.

Hvordan spore endringer i databasestrukturen etter å ha lagret en dump

Ved å lagre en dump av gjeldende databasestruktur i VCS får vi mulighet til å sjekke om det er gjort endringer i databasestrukturen etter at dumpen ble opprettet. På biblioteket skjemaholder for å oppdage endringer i databasestrukturen, er en funksjon gitt verifyDump, som returnerer informasjon om forskjellene uten bivirkninger.

En alternativ måte å sjekke er å kalle opp funksjonen på nytt saveDump, spesifisere samme katalog, og sjekk i VCS for endringer. Siden alle objekter fra databasen er lagret i separate filer, vil VCS kun vise endrede objekter.
Den største ulempen med denne metoden er behovet for å overskrive filer for å se endringene.

Hvordan overføre endringer i databasestrukturen til andre miljøer uten konflikter og gigantiske migrasjonsfiler

Takket være funksjonen deployDump Kildekoden til lagrede prosedyrer kan redigeres på nøyaktig samme måte som den vanlige applikasjonens kildekode. Du kan legge til/slette nye linjer i lagret prosedyrekode og umiddelbart push endringer til versjonskontroll, eller opprette/slette lagrede prosedyrer ved å opprette/slette de tilsvarende filene i dumpkatalogen.

For eksempel for å lage en ny lagret prosedyre i et skjema public bare opprett en ny fil med utvidelsen .sql i katalogen public/functions, plasser kildekoden til den lagrede prosedyren i den, inkludert blokken CREATE OR REPLACE FUNCTION, ring deretter funksjonen deployDump. Endring og sletting av en lagret prosedyre skjer på samme måte. Dermed går koden inn i både VCS og databasen samtidig.

Hvis det vises en feil i kildekoden til en lagret prosedyre, eller et avvik mellom navnene på filen og den lagrede prosedyren, deployDump vil mislykkes, viser feiltekst. Uoverensstemmelse mellom lagrede prosedyrer mellom dumpen og gjeldende database er umulig ved bruk deployDump.

Når du oppretter en ny lagret prosedyre, er det ikke nødvendig å angi riktig filnavn manuelt. Det er nok at filen har filtypen .sql. Etter samtalen deployDump feilteksten vil inneholde riktig navn, som kan brukes til å gi nytt navn til filen.

deployDump lar deg endre parametrene til en funksjon eller returtype uten ytterligere handlinger, mens du med den klassiske tilnærmingen må
utføre først DROP FUNCTION, og bare da CREATE OR REPLACE FUNCTION.

Dessverre er det noen situasjoner der deployDump kan ikke bruke endringer automatisk. For eksempel hvis en utløserfunksjon som brukes av minst én utløser fjernes. Slike situasjoner løses manuelt ved hjelp av migreringsfiler.

Hvis du er ansvarlig for å migrere endringer til lagrede prosedyrer skjemaholder, så må migreringsfiler brukes til å overføre andre endringer i strukturen. For eksempel er et godt bibliotek for å jobbe med migreringer doktrine/migrasjoner.

Migreringer må brukes før lansering deployDump. Dette lar deg gjøre alle endringer i strukturen og løse problematiske situasjoner slik at endringer i lagrede prosedyrer senere overføres uten problemer.

Arbeid med migreringer vil bli beskrevet mer detaljert i de følgende avsnittene.

Hvordan organisere prosessen med parallellarbeid på et prosjekt av flere utviklere

Det er nødvendig å lage et skript for fullstendig initialisering av databasen, som vil bli lansert av utvikleren på arbeidsmaskinen hans, og bringe strukturen til den lokale databasen i samsvar med dumpen som er lagret i VCS. Den enkleste måten er å dele initialiseringen av den lokale databasen i 3 trinn:

1. Importer en fil med en grunnleggende struktur som vil hete f.eks. base.sql
2. Bruke migreringer
3. samtale deployDump

base.sql er utgangspunktet på toppen av hvilke migreringer blir brukt og utført deployDumpSom er, base.sql + миграции + deployDump = актуальная структура БД. Du kan opprette en slik fil ved hjelp av verktøyet pg_dump. Brukt base.sql utelukkende når du initialiserer databasen fra bunnen av.

La oss kalle skriptet for fullstendig databaseinitialisering refresh.sh. Arbeidsflyten kan se slik ut:

1. Utvikleren lanserer i sitt miljø refresh.sh og får gjeldende databasestruktur
2. Utvikleren begynner arbeidet med oppgaven ved å endre den lokale databasen for å møte behovene til den nye funksjonaliteten (ALTER TABLE ... ADD COLUMN etc)
3. Etter å ha fullført oppgaven, kaller utvikleren opp funksjonen saveDumpfor å foreta endringer gjort i databasen i VCS
4. Relansering av utvikler refresh.sh, da verifyDumpsom nå viser en liste over endringer som skal inkluderes i migreringen
5. Utvikleren overfører alle strukturendringer til migreringsfilen, kjører på nytt refresh.sh и verifyDump, og hvis migreringen er riktig kompilert, verifyDump vil ikke vise noen forskjeller mellom den lokale databasen og den lagrede dumpen

Prosessen beskrevet ovenfor er kompatibel med gitflow-prinsipper. Hver gren i VCS vil inneholde sin egen versjon av dumpen, og ved sammenslåing av grener vil dumpene bli slått sammen. I de fleste tilfeller er det ikke nødvendig å gjøre noe ekstra etter en sammenslåing, men hvis det ble gjort endringer i forskjellige grener, for eksempel til samme tabell, kan det oppstå en konflikt.

La oss vurdere en konfliktsituasjon ved å bruke et eksempel: det er en gren utvikle, hvorfra to grener forgrener seg: feature1 и feature2, som ikke har noen konflikter med utvikle, men har konflikter med hverandre. Oppgaven er å slå sammen begge grenene til utvikle. For dette tilfellet anbefales det først å slå sammen en av grenene inn i utvikleog slå sammen utvikle til den gjenværende grenen, løse konflikter i den gjenværende grenen, og deretter slå sammen den siste grenen til utvikle. Under konfliktløsningsfasen må du kanskje fikse migrasjonsfilen i den siste grenen slik at den samsvarer med den endelige dumpen, som inkluderer resultatene av sammenslåingene.

Hvordan trygt distribuere flere endringer i databasestrukturen til et produksjonsmiljø

Takket være tilstedeværelsen av en dump av den nåværende databasestrukturen i VCS, blir det mulig å sjekke produksjonsdatabasen for nøyaktig samsvar med den nødvendige strukturen. Dette sikrer at alle endringene som utviklerne hadde til hensikt ble vellykket overført til produksjonsbasen.

siden DDL i PostgreSQL er transaksjonelle, anbefales det å følge følgende distribusjonsrekkefølge, slik at du, i tilfelle en uventet feil, kan "smertefritt" utføre ROLLBACK:

1. Start transaksjonen
2. Utfør alle migreringer i en transaksjon
3. Utfør i samme transaksjon deployDump
4. Utfør transaksjonen uten å fullføre verifyDump. Hvis det ikke er noen feil, kjør COMMIT. Hvis det er feil, kjør ROLLBACK

Disse trinnene kan enkelt integreres i eksisterende tilnærminger til applikasjonsdistribusjon, inkludert null nedetid.

Konklusjon

Takket være metodene beskrevet ovenfor, er det mulig å presse maksimal ytelse ut av "PHP + PostgreSQL"-prosjekter, samtidig som man ofrer relativt lite utviklingsvennlighet sammenlignet med implementering av all forretningslogikk i hovedapplikasjonskoden. Dessuten databehandling i PL/pgSQL ser ofte mer gjennomsiktig ut og krever mindre kode enn den samme funksjonaliteten skrevet i PHP.

Kilde: www.habr.com