Qëllimi i këtij artikulli është të përdorë shembullin e një biblioteke skema-mbajtësi tregoni mjete që mund të thjeshtojnë ndjeshëm procesin e zhvillimit të bazave të të dhënave brenda projekteve PHP duke përdorur PostgreSQL DBMS.

Informacioni nga ky artikull, para së gjithash, do të jetë i dobishëm për zhvilluesit që duan të shfrytëzojnë maksimalisht aftësitë e PostgreSQL, por përballen me probleme në ruajtjen e logjikës së biznesit të vendosur në bazën e të dhënave.

Ky artikull nuk do të përshkruajë avantazhet ose disavantazhet e ruajtjes së logjikës së biznesit në një bazë të dhënash. Supozohet se zgjedhja tashmë është bërë nga lexuesi.

Pyetjet e mëposhtme do të merren parasysh:

Në çfarë forme duhet të ruhet një skedar i strukturës së bazës së të dhënave në një sistem kontrolli versioni (në tekstin e mëtejmë VCS)
Si të gjurmoni ndryshimet në strukturën e bazës së të dhënave pas ruajtjes së një hale
Si të transferoni ndryshimet në strukturën e bazës së të dhënave në mjedise të tjera pa konflikte dhe skedarë gjigantë migrimi
Si të organizoni procesin e punës paralele në një projekt nga disa zhvillues
Si të vendosni në mënyrë të sigurt më shumë ndryshime në strukturën e bazës së të dhënave në një mjedis prodhimi

Skemambajtësi projektuar për të punuar me procedurat e ruajtura të shkruara në gjuhë PL/pgSQL. Testimi me gjuhë të tjera nuk është kryer, kështu që përdorimi mund të mos jetë aq efektiv ose mund të mos jetë i mundur.

Si të ruani një depon të strukturës së bazës së të dhënave në VCS

Bibliotekë skema-mbajtësi ofron një funksion saveDump, i cili ruan strukturën e të gjitha objekteve nga baza e të dhënave si skedarë teksti të veçantë. Dalja është një direktori që përmban strukturën e bazës së të dhënave, e ndarë në skedarë të grupuar që mund të shtohen lehtësisht në VCS.

Le të shohim konvertimin e objekteve nga një bazë të dhënash në skedarë duke përdorur disa shembuj:

Lloji i objektit
skemë
Emër
Rruga relative e skedarit

tabelë
publik
llogari
./public/tables/accounts.txt

Procedura e ruajtur
publik
auth (hash bigint)
./public/functions/auth(int8).sql

ide
prenotim
tarifat
./booking/views/tariffs.txt

Përmbajtja e skedarëve është një paraqitje tekstuale e strukturës së një objekti specifik të bazës së të dhënave. Për shembull, për procedurat e ruajtura, përmbajtja e skedarit do të jetë përkufizimi i plotë i procedurës së ruajtur, duke filluar me bllokun CREATE OR REPLACE FUNCTION.

Siç mund të shihet nga tabela e mësipërme, shtegu për në skedar ruan informacione për llojin, skemën dhe emrin e objektit. Kjo qasje e bën më të lehtë lundrimin përmes rishikimit të hale dhe kodit të ndryshimeve në bazën e të dhënave.

zgjerim .sql për skedarët me kod burimor të procedurës së ruajtur, kjo u zgjodh në mënyrë që IDE të sigurojë automatikisht mjete për ndërveprim me bazën e të dhënave kur skedari hapet.

Si të gjurmoni ndryshimet në strukturën e bazës së të dhënave pas ruajtjes së një hale

Duke ruajtur një depon të strukturës aktuale të bazës së të dhënave në VCS, ne kemi mundësinë të kontrollojmë nëse janë bërë ndryshime në strukturën e bazës së të dhënave pas krijimit të deponisë. Në bibliotekë skema-mbajtësi për të zbuluar ndryshimet në strukturën e bazës së të dhënave, ofrohet një funksion verifyDump, i cili kthen informacione për dallimet pa efekte anësore.

Një mënyrë alternative për të kontrolluar është të telefononi përsëri funksionin saveDump, duke specifikuar të njëjtën direktori dhe kontrolloni në VCS për ndryshime. Meqenëse të gjitha objektet nga baza e të dhënave ruhen në skedarë të veçantë, VCS do të shfaqë vetëm objektet e ndryshuara.
Disavantazhi kryesor i kësaj metode është nevoja për të mbishkruar skedarët për të parë ndryshimet.

Si të transferoni ndryshimet në strukturën e bazës së të dhënave në mjedise të tjera pa konflikte dhe skedarë gjigantë migrimi

Falë funksionit deployDump Kodi burimor i procedurave të ruajtura mund të modifikohet saktësisht në të njëjtën mënyrë si kodi burimor i zakonshëm i aplikacionit. Mund të shtoni/fshini linja të reja në kodin e procedurës së ruajtur dhe të shtyni menjëherë ndryshimet në kontrollin e versionit, ose të krijoni/fshini procedurat e ruajtura duke krijuar/fshirë skedarët përkatës në direktorinë e grumbullimit.

Për shembull, për të krijuar një procedurë të re të ruajtur në një skemë public thjesht krijoni një skedar të ri me shtesën .sql në drejtori public/functions, vendosni kodin burimor të procedurës së ruajtur në të, duke përfshirë bllokun CREATE OR REPLACE FUNCTION, pastaj thirrni funksionin deployDump. Modifikimi dhe fshirja e një procedure të ruajtur ndodh në të njëjtën mënyrë. Kështu, kodi shkon si në VCS ashtu edhe në bazën e të dhënave në të njëjtën kohë.

Nëse shfaqet një gabim në kodin burimor të ndonjë procedure të ruajtur, ose një mospërputhje midis emrave të skedarit dhe procedurës së ruajtur, atëherë deployDump do të dështojë, duke shfaqur tekstin e gabimit. Mospërputhja e procedurave të ruajtura midis deponisë dhe bazës së të dhënave aktuale është e pamundur kur përdoret deployDump.

Kur krijoni një procedurë të re të ruajtur, nuk ka nevojë të vendosni manualisht emrin e saktë të skedarit. Mjafton që skedari të ketë zgjerimin .sql. Pas thirrjes deployDump teksti i gabimit do të përmbajë emrin e saktë, i cili mund të përdoret për të riemërtuar skedarin.

deployDump ju lejon të ndryshoni parametrat e një funksioni ose lloji të kthimit pa veprime shtesë, ndërsa me qasjen klasike do t'ju duhet të
ekzekutoni së pari DROP FUNCTION, dhe vetëm atëherë CREATE OR REPLACE FUNCTION.

Fatkeqësisht, ka disa situata ku deployDump nuk mund të aplikojë automatikisht ndryshimet. Për shembull, nëse një funksion nxitës që përdoret nga të paktën një shkas hiqet. Situata të tilla zgjidhen manualisht duke përdorur skedarët e migrimit.

Nëse jeni përgjegjës për migrimin e ndryshimeve në procedurat e ruajtura skema-mbajtësi, atëherë skedarët e migrimit duhet të përdoren për të transferuar ndryshime të tjera në strukturë. Për shembull, një bibliotekë e mirë për të punuar me migrimet është doktrina/migrimet.

Migrimet duhet të aplikohen përpara nisjes deployDump. Kjo ju lejon të bëni të gjitha ndryshimet në strukturë dhe të zgjidhni situatat problematike në mënyrë që ndryshimet në procedurat e ruajtura të transferohen më pas pa probleme.

Puna me migrimet do të përshkruhet më në detaje në seksionet vijuese.

Si të organizoni procesin e punës paralele në një projekt nga disa zhvillues

Është e nevojshme të krijohet një skript për inicializimin e plotë të bazës së të dhënave, i cili do të lansohet nga zhvilluesi në makinën e tij të punës, duke e sjellë strukturën e bazës së të dhënave lokale në përputhje me deponinë e ruajtur në VCS. Mënyra më e lehtë është të ndash inicializimin e bazës së të dhënave lokale në 3 hapa:

Importoni një skedar me një strukturë bazë që do të quhet p.sh. base.sql
Aplikimi i migrimeve
Вызов deployDump

base.sql është pika fillestare mbi të cilën aplikohen dhe ekzekutohen migrimet deployDumpqë është base.sql + миграции + deployDump = актуальная структура БД. Ju mund të krijoni një skedar të tillë duke përdorur programin pg_dump. I perdorur base.sql ekskluzivisht kur inicializon bazën e të dhënave nga e para.

Le të thërrasim skriptin për inicializimin e plotë të bazës së të dhënave refresh.sh. Rrjedha e punës mund të duket si kjo:

Zhvilluesi fillon në mjedisin e tij refresh.sh dhe merr strukturën aktuale të bazës së të dhënave
Zhvilluesi fillon punën në detyrën në fjalë, duke modifikuar bazën e të dhënave lokale për të përmbushur nevojat e funksionalitetit të ri (ALTER TABLE ... ADD COLUMN etj)
Pas përfundimit të detyrës, zhvilluesi thërret funksionin saveDumppër të kryer ndryshimet e bëra në bazën e të dhënave në VCS
Rinisja e zhvilluesit refresh.sh, atëherë verifyDumpe cila tani tregon një listë ndryshimesh që duhen përfshirë në migrim
Zhvilluesi transferon të gjitha ndryshimet e strukturës në skedarin e migrimit, ekzekutohet përsëri refresh.sh и verifyDump, dhe, nëse migrimi është përpiluar saktë, verifyDump nuk do të tregojë dallime midis bazës së të dhënave lokale dhe deponisë së ruajtur

Procesi i përshkruar më sipër është në përputhje me parimet e gitflow. Çdo degë në VCS do të përmbajë versionin e vet të deponisë dhe kur bashkohen degët, deponitë do të bashkohen. Në shumicën e rasteve, nuk ka nevojë të ndërmerren veprime shtesë pas një bashkimi, por nëse janë bërë ndryshime në degë të ndryshme, për shembull, në të njëjtën tabelë, mund të lindë një konflikt.

Le të shqyrtojmë një situatë konflikti duke përdorur një shembull: ka një degë zhvilloj, nga e cila degëzohen dy degë: feature1 и feature2, të cilat nuk kanë konflikt me zhvilloj, por kanë konflikte me njëri-tjetrin. Detyra është që të bashkohen të dy degët në zhvilloj. Për këtë rast, rekomandohet që fillimisht të bashkohet një nga degët në zhvillojdhe më pas bashkohen zhvilloj në degën e mbetur, duke zgjidhur konfliktet në degën e mbetur dhe më pas duke bashkuar degën e fundit në zhvilloj. Gjatë fazës së zgjidhjes së konfliktit, mund t'ju duhet të rregulloni skedarin e migrimit në degën e fundit në mënyrë që të përputhet me deponimin përfundimtar, i cili përfshin rezultatet e bashkimeve.

Si të vendosni në mënyrë të sigurt më shumë ndryshime në strukturën e bazës së të dhënave në një mjedis prodhimi

Falë pranisë së një deponie të strukturës aktuale të bazës së të dhënave në VCS, bëhet e mundur të kontrollohet baza e të dhënave të prodhimit për përputhjen e saktë me strukturën e kërkuar. Kjo siguron që të gjitha ndryshimet që synonin zhvilluesit të transferoheshin me sukses në bazën e prodhimit.

Si DDL në PostgreSQL është transaksionale, rekomandohet t'i përmbaheni urdhrit të mëposhtëm të vendosjes, në mënyrë që, në rast të një gabimi të papritur, të mund të ekzekutoni "pa dhimbje" ROLLBACK:

Filloni transaksionin
Kryeni të gjitha migrimet në një transaksion
Në të njëjtin transaksion, ekzekutoni deployDump
Pa përfunduar transaksionin, ekzekutoni verifyDump. Nëse nuk ka gabime, ekzekutoni COMMIT. Nëse ka gabime, drejtojeni ROLLBACK

Këta hapa mund të integrohen lehtësisht në qasjet ekzistuese për vendosjen e aplikacionit, duke përfshirë kohën e ndërprerjes zero.

Përfundim

Falë metodave të përshkruara më sipër, është e mundur të shtrydhni performancën maksimale nga projektet "PHP + PostgreSQL", duke sakrifikuar relativisht pak lehtësi zhvillimi në krahasim me zbatimin e të gjithë logjikës së biznesit në kodin kryesor të aplikacionit. Për më tepër, përpunimi i të dhënave në PL/pgSQL shpesh duket më transparent dhe kërkon më pak kod sesa i njëjti funksionalitet i shkruar në PHP.

Burimi: www.habr.com

Logjika e biznesit në bazën e të dhënave duke përdorur SchemaKeeper